Last week Apple delivered on a promise: Its Swift language is now open source. Unveiled a little more than a year ago, Swift is part of the C family, designed with an eye toward general-purpose application development. The initial Apple releases of Swift focused on the development of new desktop and mobile apps, using the LLVM compiler. The result is a new language that takes advantage of much current thinking in language design, mixing the complexity and depth of C with the ease of use of interpreted languages like Python. It’s also fast, designed to work well with large arrays and collections.
The open source release of Swift continues the language’s development, adding both Linux support and server-side language features. Swift was already on a fast track: In the year or so it has been available, Swift has jumped to version 2.2, adding language-specific features to the LLVM and clang compilers. There is no Windows version of Swift yet, though Microsoft has added Swift support for iOS and OS X applications in its latest Visual Studio releases.
If you’re working with Swift on OS X, Swift in Xcode is very much the same, familiar development environment that Objective-C developers have used for years, with the two languages drawing on the same compiler. Apple has described Swift as “Objective-C without the C.”
That’s because Swift is really an abstraction of Objective-C and the underlying LLVM compiler. In fact, Swift is so closely related to Objective-C, you could almost describe Swift as a new dialect of Objective-C that simplifies certain key constructs and makes code more readable. Swift builds upon Objective-C’s syntax with support for modern constructs that both simplify the language and make it more accessible to developers who are coming to iOS or OS X development from JavaScript or C#. These developers will find a lot that’s familiar, from the way Swift handles control flow to how it uses functions.
The commonality between Swift and Objective-C simplifies the process of updating apps to the new language. You’re able to mix and match Swift and Objective-C code in the same app, so you can reuse existing libraries in new apps. If you’re moving from the one language to the other, you don’t have to rewrite code you want to reuse, unless you really want to.
Apple’s design principles are focused on safety, and one of Swift’s key features is support for type inference. As a result, while Swift is not strongly typed, it is type safe. If you fail to declare a variable type, but you set the variable to a value that’s already been declared, then Swift infers it’s the declared type. That makes your code safer -- reducing the risk of crashes. Swift also restricts access to pointers with its own memory management.
Type safety also means you can never pass an int to a string; the Swift compiler will always flag this as an error. A guard statement will stop a section of code from executing if its value is nil, allowing you to ensure that you’re able to protect code from common user and API errors (normally a nil causes a compiler time error). Alternatively, you can use optionals to allow specific variables to be nulls, no matter what type they implement.
Writing a Swift app is easy enough: You simply start. There’s no need to set up a main function or import references. It’s an approach that’s designed to make coding more accessible. While much of the OS X or iOS user interface is handled by libraries, you can get started with the core of an app before you give it a look and feel.
One key element of Swift is what Apple calls “protocol-oriented programming.” Closely related to interfaces in other languages, protocols require a class to implement specific methods, so you can always use the defined method with any class that uses a protocol. Protocols allow you to extend any class -- including core language elements -- without having to edit its source code. That means you can work with third-party code and libraries.
Another big benefit: You can provide your development team with a set of protocols that implement your coding standards. Protocols are an extremely powerful tool, one that makes generics a key element of your development strategy.
Perhaps Swift’s most important innovation is the addition of Playgrounds to Xcode. Apple is using Xcode and Swift to expose more of the LLVM compiler to its developers, with the ability to see what code does from inside the IDE. Playgrounds let developers quickly try out sections of code to see if they do what they want without leaving the IDE. There’s no need to compile code and run builds or debuggers; it’s all there next to the code you’ve written. The approach is designed to encourage experimentation -- and yes, play -- with code.
Taking those features to other platforms is an important step. Languages need to be available wherever developers are working, from client to server to cloud, and a consistent language across all elements of the modern stack is key to efficient development. You don’t get Playgrounds in the Swift compiler on Linux.
Then again, given the focus on server application development there, you’re not really going to need to quickly visualize a function -- at least not beyond dumping the output to a console. Apple is delivering a REPL-based debugger as part of its Linux tooling, allowing you to quickly work with your code in an interactive manner, so you can use the Read-Eval-Print-Loop tools as an expression evaluator
With the source code for Swift now on GitHub, anyone can now fork the original repository, experiment with the code, and make pull requests to contribute code back to Swift. Perhaps the most important element here is Swift’s core libraries, as they promise the option of extending Apple’s development frameworks to other platforms. Being able to build Swift code once, and deliver to multiple platforms, will give developers an alternative to Microsoft’s open source .Net, and allow cross-platform tooling companies like Xamarin to support a much wider group of developers.