Mark this date:
December 3, 2015 - the day
Swift has become
open source! It is absolutely amazing that we are now able to look back into the history of
Swift and see its evolution; for example the first commit was made by who else but
Chris Lattner, in
July 2010. There has been a tremendous interest for the
Swift main repository, with almost 20k stars and 2k forks in just the first few days. A total of 17 repositories were made public by
Apple. There have even been a few pull requests accepted and merged, the most notable one being the removal of the ++ and – operators, as well as of the C-style for loop syntax, all this in the upcoming
Swift 3.0 version. If that was not enough, the Perfect project is already using server-side
Swift, and here is also a HTTP server written in
So what have we got? First, a new website as the Swift home; here you can find the new
Swift blog, the
Swift binaries for
OS X and
Getting Started guide, the
Documentation page from where you can download the most recent Swift Programming Language ebook (currently the 2.2 version), among other resources. Second, we got all the source code grouped in no less than 17 repositories. The most notable ones are:
- Swift main which contains the source code for the
Swiftcompiler, standard library, and
- Swift evolution which contains documents related to the continued evolution of
Swift, including goals for upcoming releases proposals for changes to and extensions of
- Swift corelibs - there are 3
corelibsrepositories but the most important one is
Foundation, which contains the source code for
Foundation, which provides common functionality for all applications.
- Swift package manager which contains the source code for
Package Manager- a tool for managing the distribution of
Swiftcode. It’s integrated with the
Swiftbuild system to automate the process of downloading, compiling, and linking dependencies.
I will conclude this article with an invitation to
contributing to open source code. There are several ways you could get involved:
- the easiest entry way to contributing is to
documentsource code - there are plenty of places that need comments and descriptions.
- another easy way is to add more
unit testingwhere the code does not have enough coverage.
- going further to more advanced ways, you can search for FIXME marks inside the code and attempt to fix them.
- also, there are many NSUnimplemented() marks in the
Foundationcode base that you could attempt to implement.
- finally, and this is the hardest part, try to resolve
bugsfrom the Swift issues list.
Until next time!