Apple's Swift and Swift 2 explained: What it is and what it means

One of the biggest WWDC announcements was something most users will never see. CNET breaks down Swift and its successor, Swift 2.

Apple's Swift
Tim Stevens/CNET

People tend to forget that the "D" in Apple's WWDC stands for "Developer" -- that this is, indeed, a developer conference, a place where coders can come and learn new tricks for their chosen trade.

This message was squarely driven home by today's focus on two things: software and the people who create it.

While some folks out there are disappointed about the lack of new hardware from the Worldwide Developers Conference this year (new iPhones, iWatches, and so on), it's software that makes these devices actually worth owning, and perhaps someday worth wearing. So, many of the updates we saw today make developers' lives easier. Happier developers mean more apps -- and better ones, too.

The biggest announcement for developers from WWDC '14 by far was Swift, a wholly new programming language intended to not only make writing those apps much easier, but also faster and more stable, while creating results that perform better in the end. Basically, it's promising to be all things to all coders. Is that possible?

At WWDC '15, Apple updated Swift to Swift 2, and made the whole thing Open Source. Does that really change the game?

That remains to be seen, but from what I saw today, it looks like it has potential. Join me as I break down what Swift is and what it means. Trust me, I'm a developer -- or at least I used to be.

Types of programming languages

Apple Swift
Swift is billed as "Objective-C without the C." Tim Stevens/CNET

There are a lot of ways to get a device to do something, whether that gadget is hip and fresh like a smartphone or something a little more boring like a laptop or PC. The most hard-core way to do so is to write in raw bytecode, or something like assembler, where the programmer basically crafts each and every instruction by hand -- every time a number is changed in memory, every time a pixel changes on the display, every single possible action. Good developers can do great things coding this way. But as you can imagine, writing apps like this is incredibly tedious and error-prone.

That's where high-level languages help. Here, instead of a one-to-one relation between what the programmer writes and what the computer does, a programmer can write a given command, and that will result in the computer possibly doing multiple things. High-level languages are a lot more like real languages in that they have syntax and a formal structure with some nuance.

Imagine telling someone to get you a soda from the fridge. In a high-level language, you'd say, "Get off the couch and get me a soda from the refrigerator" and the person would figure out how to do that. With a low-level language, you'd need to say something more like, "Place both feet on the floor. Use your arms to stand up from the sofa. Place your right foot in front of your left foot, now your left foot in front of your right foot..." You get the picture. Every single discrete action between the couch and kitchen would need to be described exactly.

C is a classic high-level programming language, and a flavor of it, Objective-C, has traditionally been Apple's language of choice. Amazingly, Objective-C been around for over 30 years, and C itself for over 40. You can imagine that it might be time for something new.

Among these programming languages there is a subset called a "scripting" language. This distinction is a little harder to explain, but bear with me. Basically, a traditional high-level programming language needs to be compiled before anything will happen. Compiling is when all those commands (like "go to" or "get") are translated into specific instructions that the computer can understand.

The syntax is split apart from something a human can read into something a computer can read and, if all goes well, the result of that is an application that actually does something -- ideally, the thing you wanted it to. This compilation process is often slow, and it needs to complete before you can see whether the program you've written works. Any little glitch in your syntax often won't be identified until well into the compilation process, slowing down the development process.

A scripting language, on the other hand, executes as it goes, line-by-line. You can see the results more easily as you're writing it, and you don't need to sit around and wait for compilation. This makes development fast and (relatively) easy, but often scripting languages are limited in their abilities -- they're typically used for simpler stuff. More problematic, their performance is often limited. This won't do in many cases.

Python is an example of a language that is commonly used for scripting, and indeed it's the language that Apple compared against onstage at WWDC.

Swift: The best of all the above?

Apple Swift
The logo for Swift, Apple's new programming language. Tim Stevens/CNET

Scripting languages, like Python, tend to be easy to write and easy to test, but they aren't particularly powerful and generally don't perform well. Not ideal when you're writing, say, a game that needs access to the full power of your device. Traditional programming languages, like Objective-C, give better access to the power of the device and enable the creation of more comprehensive apps, but are difficult to learn and tedious to compile and test.

Swift promises to have all the good with none of the bad. Apple promises that, at least in a few key benchmarks, it is considerably faster to execute than Python and faster even than Objective-C. But, despite that, the language supports what's called "playgrounds" within the Xcode developer environment, visualizing Swift code in real-time, like a scripting language.

Apple Swift
Tim Stevens/CNET

As an example today, a developer wanted to make a game where a balloon moved up and down in a regular pattern. To do that, he wanted to use a simple mathematical function -- sine, which you may remember from your trigonometry days. Sine gives you a nice waving arc, above and below zero, which is perfect for a floaty balloon.

In Swift, the developer was able to assign the value of sine to the balloon easily, and then see how that value changes over the execution of the app in a simple line chart. This makes it incredibly easy to visualize how that balloon is going to move so that if that's not appropriate, that can be changed immediately. Traditionally, the developer would have to run code through a compiler and then execute it and hope for the best. That process, depending on the size of the app, can take anywhere from a few seconds to a few minutes or more.

Immediate benefits

Having the ability to quickly and easily test an app as you write it has the potential to let developers create complex apps more quickly. The compilation and testing process can become hugely cumbersome on a sizable app. If Swift can make a major impact there, as it seems to, that will enable application developers to release more thoroughly tested apps more quickly.

Additionally, Swift is a very terse language. That is, much like Python, you don't need to write a lot to get a lot done. This, too, could speed up app development.

Finally, if Swift proves to create apps that execute more quickly than those in Objective-C, we could see even more impressive graphics in games (with the help of Apple's new Metal interface, which is another can of worms) and more responsive behavior from other apps, all without having to buy a new phone.

Immediate concerns

It's not all roses, and the big immediate concern -- which was echoed by a few developers that I spoke with -- was the requirement to learn a whole new language. Coders in general enjoy mastering the latest and greatest. But there's an entire industry that has sprung up around teaching people how to write iPhone apps. All that, effectively, goes out the window as of today. (Yes, you can continue to create Objective-C apps, but nobody's going to want to.)

The other concern, which isn't much of a worry in my mind, is that by lowering the barrier of entry with an easier to learn, easier to use language, you'll result in more rookie developers launching apps that simply aren't very good. That is indeed possible -- even likely -- but the same could be applied to basically any improvement in software development since the first programming languages in the '40s. Surely, someone somewhere still thinks everyone who isn't doing it on punch cards is an amateur.

Moving to Swift 2, and Open Source

At WWDC '15, Apple announced Swift 2. A number of updates were included, like better debugging, mutability checking and Markdown in comments. Nice stuff, but bigger is the support for other platforms. Swift 2 developer tools will now be available for Linux, opening the door for Apple app development on non-Apple platforms.

The biggest news, however, was making the entire platform Open Source. That means that all developers will be able to look into the actual source code of Swift itself. Developers will be able to use this information to developer their own developer tools and, potentially, their own compilers. This means we could potentially see Swift apps actually running on non-Apple platforms.

That seems a little unlikely to me, but with the new version of Swift and its better tools we should see yet more power in the hands of developers, meaning better apps for all in the future.

'Hello, world'

Tim Stevens/CNET

Swift has been out there for a year now and developers are still cutting their teeth on the platform. With Swift 2 on the horizon, the language gets even more powerful and, more importantly, available to more developers on more platforms. More power for more developers means more apps, and better apps, and that's good news for us all.

Featured Video
This content is rated TV-MA, and is for viewers 18 years or older. Are you of age?
Sorry, you are not old enough to view this content.

Acer introduces a stackable, modular PC

Acer intros a modular PC; the PS4's next update is a big one; why renting cable boxes is crazy; and Google's war on full-screen mobile ads.

by Jeff Bakalar