Apple to Open Source Swift Language

Write for InfoQ

At today's WWDC 2015, Apple announced a new revision to their Swift programming language, Swift 2.0. Since being launched at WWDC 2014, Swift has undergone a couple of minor point releases and added minor syntax functionality and an extended API with Swift 1.1 in October 2014 and Swift 1.2 in April 2015. Swift is a language that has been several years in the development, being based on LLVM as the runtime engine and using techniques and tools from the Clang compiler to provide a type-safe, statically typed programming language that can interoperate with Objective-C frameworks and libraries.

Swift 2.0 brings "even better performance, a new error handling API, and first-class support for availability checking. And platform APIs feel even more natural in Swift with enhancements to the Apple SDKs" according to the release blog post. In addition, better integration with existing Apple SDKs has been improved thanks to extensive nullability and generics annotations, which was first introduced in Swift 1.2. The error handling uses industry standard try, catch and throw keywords rather than archaic C conventions of returning nil. Error handling is a language feature, not a programmer constraint. Protocol extensions now allow existing protocols to adopt new methods in a similar way to Objective-C categories, allowing for greater flexibility in the way programs are written. Extensive updates to the core Swift library have been done to use the new feature instead of global functions.

Swift 2.0 also adds the ability for a program to be compiled for both older and newer versions of Swift, allowing programs to use selective availability to conditionally compile code for newer platforms, similar to the weak linking available in Objective-C using the NS_AVAILABLE macro. A new keyword defer allows code to be associated with cleaning up at the end of a block, similar to Go's defer statement.

Having lasted for over 30 years, the Objective-C runtime was starting to show its age in the ever increasing mobile space. Being a dynamically dispatched language, messages sent to objects in Objective-C paid a per-message cost in the objc_msgSend function. Furthermore, an optimising compiler cannot inline dynamically dispatched methods, resulting in application code needing to defer to runtime the code paths through the application.

Swift solves this problem by being a statically dispatched language, like C++. Methods in Swift are compiled into a per-class vtable, which the optimisnig compiler can now see and perform in-lining of methods. (It is a generally accepted fact that the majority of optimisations in JITs occur because methods become in-lined, exposing further peephole optimisations that are not visible in the part.) Although Swift doesn't have any run-time JIT optimisations (all the optimisations are done at compile time), the fact that Swift's language is fairly simple allows the compiler to generate efficient code for methods and functions.

In addition, Swift allows structures to be treated as objects. They gain the storage efficiency of C but with the power of C++. A large array of Swift structures is both typesafe and efficiently stored, which is a benefit for small data types. The collections classes are also generic, unlike Objective-C, which means the contents can be stored safely.

The two things missing from Swift 1.x were a standard ABI (which permits frameworks to be written in Swift) and an open-source implementation. With the release of Swift 2.0, Apple has promised that Swift will be open-sourced under a permissive OSI-approved open-source license, and will run on not only iOS and OSX but also Linux. With the standard libraries and compiler being available for the most widely used server-side operating system, the explosion of non-OSX frameworks are sure to come. It's unlikely that Xcode IDE will be open-sourced, leaving other IDEs to pick up the strain of Swift programming. Since LLVM and Clang are released under the Clang BSD license it is likely that Swift will be released under a similar license.

The Apple developer program, which used to have different OSX and iOS developer requirements, has been updated to a single developer account, including watch OS. Furthermore, developer membership is no longer required in Xcode 7 to install applications on an iOS device, although a (free) Apple account is still required.

Updates: this post has been updated to include the new defer keyword, the link to the blog post confirming that it will be released under an OSI approved permissive license, and the updates to the Apple developer account. Also confirmed that Xcode 7 allows side-loading of iOS applications without a developer program.

Related Topics:

• Development
• DevOps
• Swift
• Mobile
• iOS
• Infrastructure
• Mobile Development
• Functional Programming

We protect your privacy.