The Swift open source release evolves

The practicalities of the Swift open source release and what it means for non-Apple developers.

By Paris Buttfield-Addison
January 6, 2016
Hummingbirds and Swifts Hummingbirds and Swifts (source: Pixabay)

In the last post, we gave an overview of why Swift is exciting, from a language perspective. In this post, we’ll review the situation with the open source release of Swift.

The open source release of Swift consists of three main items:

Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

Learn more
  • The Swift.org website, which is the official website for the language, provides a central location for information about the language, the project, and its associated projects. It’s the best place to go if you want to get as much information as you can about the open source release.

  • The Swift project on GitHub is the main source code repository for the Swift compiler. This repository also contains certain essential components, such as the Swift standard library (which contains the code for necessary things like strings, arrays, and so on.)

  • As well as the main Swift compiler project, there are a number of additional subprojects that support the Swift language infrastructure. These include the Swift Package Manager, an open source Swift release of the Foundation library (which provides features like networking and text processing), and the Swift Evolution project, which contains no code at all and is potentially the most exciting of all. We’ll talk more about the Swift Evolution project in a moment.

The fact that Apple is providing a complete, open source, Swift-written implementation of the Foundation library is especially cool. Foundation is the library that provides the majority of useful tools for application writers, such as file management and concurrency. Previously, this was a closed-source package; now, more and more is being opened up.

Swift, and a collection of associated projects, are licensed under the Apache 2.0 license. This license is OSI approved, and basically gives you permission to do what you like with the code, as long as you indicate where the code originally came from and, if you redistribute the code, indicate what changes were made. (Disclaimer: We’re not lawyers, and you should chat to a lawyer if you want legal advice regarding using the Swift code.)

Swift’s license also includes a specific exception for the Swift runtime library. This means that if you compile a Swift program, chunks of Swift code will be included in the binary in order for it to work. You’re specifically given permission to not comply with the Apache license’s terms for attribution for these specific components.

While the Swift open source package is quite complete, there are several things that are not included. These include:

  • Any support for Windows. Currently, Swift only supports Linux, in addition to Apple’s platforms. Craig Federighi, Apple SVP of Software Engineering, in an interview with John Gruber, stated that official Windows support will depend on how interested the wider community is.

  • Large chunks of the open source Foundation library are currently not yet implemented. These are slowly being filled in, both by Apple developers and by the community. This means that, until it’s more complete, Swift developers on non-Apple platforms will need to wait for the complete feature set to arrive before the entire library can be considered ready for production use. However, this doesn’t necessarily mean that Swift as a language isn’t ready for production use–just that certain higher-level features are still arriving. On Apple platforms, the proprietary version of the Foundation library is still fully available, as normal.

In addition, the Swift Package Manager is not yet complete; however, it’s approaching release, and looks to be very useful once it has been finalized. The inclusion of the Swift Package Manager is particularly interesting. The package manager acts as a tool for downloading and managing packages of external code used by your application. Package managers for Swift have existed before, but have all been provided by third parties: these include tools like CocoaPods and Carthage. In the Swift Package Manager, we have an official, Apple-endorsed package manager, which is a very good thing. It remains to be seen whether the Swift Package Manager will be a better choice than the more established projects, CocoaPods and Carthage, but chances are high that the ‘official’ solution will become the defacto standard.

The most exciting part of the Swift open source project, in our opinion, is the Swift Evolution project. This project is in charge of the future direction of the Swift language; importantly, Apple has declared that all development of Swift will take place in public, and that they will accept contributions from the community. These contributions are not just code; they include things like decisions on what the language will and will not contain.

An example of this in action is Erica Sadun’s proposal to remove for-loops from the language, on the basis that they are rarely used, included only as a holdover from the predecessor language Objective-C, and that more modern techniques (such as using forin loops with the enumerate function) achieve the same result. After submitting the proposal to the Swift Evolution project, it was debated by the maintainers of the language, and finally accepted. As a result, for-loops are being removed from Swift 3.0.

Swift’s community enhancement proposals are open for anyone to submit to. For more information on how you can get involved in the future of the Swift language, read the community contribution guidelines. It’s never been a more exciting time to be involved in this language, and the structure of the open source project is surprisingly solid, and encouraging of contributions from code to documentation, and everything in between.

For developers currently working on Apple platforms, the release of Swift into the open means that we’ll have a better picture of what Apple’s moves are. It’s likely that we’ll see Apple telegraphing their intentions for developers, both on this project and others. For developers interested in using Swift on non-Apple platforms: it’s not quite ready for production there, but you can and should start learning it now.

Our next post on Swift will cover possible uses of Swift in the future, such as on servers, and for apps on non-Apple platforms. Stay tuned!

Post topics: Open Source
Share: