Download code from GitHub
Apple's release of Swift was a smashing hit from the very beginning. The language generated a lot of hype and it delivered. Of course, with the introduction of any new programming language, problems and issues will come along for the ride. Apple has carefully cultivated the young language, and has been steadily improving its base and introducing new features, support, and compatibility with its long mainstay incumbent, Objective-C. So, why would Apple open-source the language? What is Apple's objective and what does that tell us about the forthcoming release of Swift 3?
The focus of this chapter is to discuss Apple's goals for Swift 3, to show you where you can find the source of official information about new and current development in the language, and to explain how the community of developers will shape the fate of Swift as a language.
During the What's New In Swift lecture from Apple's World Wide Developer Conference (WWDC) 2016, Apple engineers outlined several goals for the upcoming release of Swift 3:
Develop an open community
Portability to new platforms
Get the fundamentals right
Optimize for awesomeness
Note
If you missed the conference, you can watch a replay of the talk on Apple's developer portal. Here's the link for What's New In Swift: https://developer.apple.com/videos/play/wwdc2016/42.
I want to briefly touch on a couple of themes here as it will provide a base for the material you will find in the remaining chapters:
Apple believes that for Swift to grow in adoption it needs a strong community. The path to rapid Swift adoption is to include the voices of the community in its development.
Swift is a general-purpose language that could and should run on any platform. Imagine running Swift on Linux or on the Internet of Things (IoT) you create or need to control. Apple believes that the Swift language is so capable that they removed the barriers that tied Swift to running on a Mac, opening endless possibilities for platform portability. Apple wants the community to find ways to get Swift to run on other platforms. Today, the Swift team is supporting a port to Linux. Tomorrow, the Swift team could have official support for a wide range of platforms.
In order to make the first two themes possible, the Swift team needs to get things right from the beginning with Swift 3. Unfortunately, this means that the new changes in Swift 3 do not work well with previous releases of Swift. The Swift 3 release will fix and remove things that were awkward in Swift 2 (and its predecessors). Swift 3 also re-imagines how it interacts with Cocoa and Objective-C to make the APIs that bridge them feel more Swifty.
Swift is a really big deal to Apple and expectations from the language are high. Apple has laid out its roadmap for how it expects to reach its goals. In fact, you can stay current with all things Swift by subscribing to one of the mailing lists found here https://swift.org/community/#mailing-lists. The main method for communicating with the Swift community is via mailing lists. You can find mailing lists that cater to general information as well as lists for day-to-day updates on the language. The Swift mailing lists can be a valuable tool that you should not overlook.
In the next section, we will talk about what the open source community means for you as a Swift developer.
On December 3 2015, Apple open-sourced Swift (including the language, supporting libraries, debugger, and package manager) under the Apache 2.0 license and launched the https://Swift.org/ website on the same day. https://Swift.org/ is the official site to find resources on the various projects that make up Swift. It's your main source to read announcements on all of the development work on the language, from proposals of new features, to links to development branches of Swift code that you can download and test.
https://Swift.org/ is a website that you will want to bookmark for future reference. The entire Swift codebase is hosted on GitHub and is available for anyone to access. Take a second to think about that. Anyone can download Swift, play around with a binary, build a project, or look under the hood to see how things actually work. For a company of Apple's size and reputation, releasing Swift, the language that they are betting on to power all of their applications, to the community is amazing and should not be taken lightly. This is huge!
Naturally, Apple didn't just hand the language over and walk away. Instead, Apple set up an internal team to shepherd the development process and to be responsible for the day-to-day project management. The open sourced version of the Swift language is comprised of a group of projects each hosted as a separate repository on GitHub. Today, you can find links to six active projects:
Swift compiler: Command line tool
Standard library: Distributed as part of the core language
Core libraries: Provide a higher level functionality
LLDB debugger: Includes the Swift REPL
Swift Package manager: Building projects and distributing them
Each project has a dedicated section on https://Swift.org/ that explains the project goals and links on how to use both Swift and contribute as a community member. I encourage you to review https://Swift.org/ to get a better handle on all things Swift from Apple's perspective. Before we end our section on where to find resources on Swift, I do want to briefly discuss what it means to be a community contributor.
The community structure has been well thought out and it's designed to provide strong leadership from members in the community. This structure will guide the on-going development of the language and will hopefully ensure that as the community expands, many new community contributors will have a voice that is heard and respected. See below for the roles that make up members of the community:
Project Lead: Apple is the project lead and will select others from the community to serve in various technical lead positions
Core Team: This small team of engineers is responsible for strategic direction
Code Owner: This title goes to anyone responsible for a specific area of a Swift project codebase
Committer: This role is given to anyone with commit access to a Swift repository
Contributor: This role is reserved for anyone who contributes to a patch or helps with a code review
You can read more about the individual roles in the community on https://Swift.org/ under the community section. The Swift community is growing and, not unexpectedly, many developers are curious about how to contribute. With that in mind, let's explore how things get done.
There are a few ways that you can help make the community and Swift better. Surprisingly, it's not just by cranking out code. The community needs support with answering questions on the mailing lists. Your answers could range from helping a newbie get a better grasp on a new concept to, going to the opposite extreme, helping a seasoned developer work through a subtle bug. Either way, contributing your knowledge could be valuable to others and would be very much appreciated!
The next option for contributing to the Swift project is by either reporting or triaging bugs. The Swift team uses Jira for defect tracking and you can submit bugs on the project's Jira instance located at https://bugs.swift.org.
The final option you have as a developer is to contribute code. There is a formal process for committing code that we will briefly cover. The Swift project prefers small incremental changes to large commits or long-term disconnected feature branches. The Swift team also encourages, but does not enforce, commit messages that describe in detail what your committed code changes include. Code quality is extremely important and is emphasized through mandatory code reviews and pull requests to ensure at least another set of eyes has reviewed all code changes. Think of it this way; your changes will eventually make it into a production environment and have the potential to affect millions of developers that use the Swift language. Do you really want to take of chance introducing a defect that might affect millions of developers?
While Apple and the Swift team each have tons of great ideas on where Swift can go, it's important to remember that they aren't the only ones with ideas. In fact, the Swift team fully realizes this, and in response has created a process for you to submit your big or small ideas to help shape the Swift language.
The Swift evolution process encompasses all things related to taking a raw idea from inception through discussion and dialog and hopefully ending at an accepted proposal that developers can implement for production release. The goal of the process is to have active engagement within the community in order to steer the direction of the language while remaining true to the vision of Swift. In practice, that might translate into adding new features that make the language easier to use or removing features that no longer fit the vision of Swift. You can participate by proposing a new idea, or discussing and reviewing the proposals of other community members.
Swift evolution proposal steps
Here are the steps required to get a new idea moved into an accepted proposal:
Check for similar proposals: It's important to do your homework and make sure that your idea hasn't already been proposed and/or rejected. Spend time reviewing proposals and their states. You can check the Commonly Rejected Proposals list for this task.
Tell others about your idea: Most of the discussions around new ideas take place on the swift-evolution mailing list. This is where you should create a draft of your idea, along with the problem it addresses and some context on a solution.
Create your proposal: Using the proposal template found here https://github.com/apple/swift-evolution/blob/master/0000-template.md, you elaborate on your idea and continue to socialize it on the evolution mailing list.
Request a review: When you believe your proposal is ready for a formal review by the core team, you submit a pull request to the swift-evolution repository https://github.com/apple/swift-evolution. When your pull request is accepted, your proposal will be given a proposal number and assigned a core team member to facilitate the review.
Respond to feedback: It's your job to respond to questions and feedback on your proposal on the mailing list. This is especially important during the review period.
If all goes well, your proposal will navigate through the proposal states below during the review process and will be accepted.
Awaiting review: Until the proposal is assigned a date period for review, your proposal remains in this state.
Under review: Your proposal is undergoing public review on the swift-evolution mailing list.
Under revision: If you are given feedback during the under-review state, you are given an opportunity to address and modify your proposal.
Deferred: Decision postponed because it doesn't meet the criteria for the upcoming major Swift release. In this state, your proposal will be reconsidered when scoping for the next major Swift release.
Accepted: Accepted and new work can begin or is actively being done to implement your accepted proposal. An announcement will also go out to let the community know of a new accepted proposal for the upcoming release.
Rejected: Considered but rejected by the core team.
Here are some key things to remember about the review process. It doesn't start until a core team member (review manager) accepts your pull request for the proposal. Once accepted, the review manager will coordinate a review period with you and any other authors of the proposal to start a formal public review. The review period is a week long in most cases, but can be longer depending on the scope and complexity of changes outlined in the submitted proposal. Finally, the core team, not just the review manager, will make a decision on the proposal using the comments from the swift-evolution mailing list to help base their decision.
Each major release of Swift will have high-level goals to which accepted features must adhere. For the Swift 3 release, the Swift team outlined that the primary goal of this release is to solidify and mature the Swift language and development experience.
In their own words, the Swift team went on to stated that While source code breaking changes to the language have been the norm for Swift 1 through 3, we would like the Swift 3.x (and Swift 4+) languages to be as source-compatible with Swift 3.0 as reasonably possible. However, this will still be best-effort: if there is a really good reason to make a breaking change beyond Swift 3, we will consider it and find the least invasive way to roll out that change (for example, by having a long deprecation cycle).
In order to achieve the release goal for Swift 3, each of the following are considered important in terms of getting the basics right for future releases:
API design guideline
Automatic application of naming guidelines to imported Objective-C APIs
Adoption of naming guidelines in key APIs
Swiftification of imported Objective-C APIs
Focusing and refining the language
Improvements to tooling quality
You can learn more about each of these areas on the Swift Evolution repository page as well as see the complete list of implemented proposals, accepted but not yet implemented proposals, and rejected or withdrawn proposals.
In this chapter we discussed Apple's goals for Swift 3 and the importance of the community's engagement and involvement to the language's development. I also showed you where to find the source of official information about new and current development on the language. Last, we learned how the community can contribute to the development process of Swift as a language. In Chapter 2, Discovering New Territories – Linux at Last! We go over developing Swift on Linux.
