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:

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:

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:

If all goes well, your proposal will navigate through the proposal states below during the review process and will be accepted.

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:

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.