Swift Developments is a hand-curated newsletter containing a weekly selection of the best links, videos, tools and tutorials for people interested in designing and developing their own apps using Swift.
Welcome to another week of the AndyBargh.com Newsletter. So, unless you’ve had no power all week or were marooned on a desert island, you’ll probably know by now that last Thursday saw Apple deliver on it’s promises to the development community. With 28 days to spare to it’s “before the end of the year” deadline (and just 2 hours after I published last weeks newsletter), Apple released the Swift Programming Language to the open source community publishing a whole range of goodies for us developers to dive into. In honour of this fact, this weeks newsletter is unashamedly Swift oriented…
We’re going to kick off this weeks newsletter with this article from Ars Technica. Published on Thursday, the article is an in-depth interview with Craig Federighi, Apple’s Senior Vice Precident of Software Engineering in which he discusses why Apple have open-sourced Swift and how they plan to run the project. The article also provides some insights into Apples future plans for Swift as well as the future of Objective-C.
So here it is, the new home of open source Swift. If you want to take a look around, the new site provides a variety of resources including binary distributions for both Ubuntu Linux and OS X, source code hosted with GitHub and getting started documentation should you want to dive in yourself.
Along with the documentation comes a complete outline of how the Swift open-source community will be run. For me, this is one of the more impressive things amongst the things that Apple have released. To me it shows that there has been some serious thought about what type of community they want to surround the project and is a great example of things to consider if you are thinking about open sourcing your code.
I included this link for a number of reasons. Firstly, it really surprised me how long @clattner_llvm and the team had been working on the Swift language. The first commit was way back in 2010 and you can see from the 20,000+ commits that a lot of work has gone into it since. Secondly, it’s testament to Apple that we are actually getting see this sort of information. I’m really impressed that they’ve got fully behind this project and not only released the code, but with it released the full commit history of Swift, warts and all. It provides great insight into the development of the language over time. If nothing else, it’s also a great reminder that every project starts with small steps.
So having looked at where the Swift code base has been, we move onto where it is going. One of the interesting things over the past week has been keeping an eye on the various proposals for what will be added and removed from future versions of Swift. The main focus seems to be stability and resilience which should help reduce the number of code changes we need to make as we move between versions going forward but if you’re interested, it’s now all out in the open for everyone to see.
API Design Guidelines
In my opinion one of the little gems within the material that Apple released was the API Design Guidelines document. Although they are still in draft and are being developed as part of the effort to release Swift 3.0, they are a great read and provide some well articulated guidelines and best practices that you should adopt when writing your own Swift code. Definitely worth a read.
Picking up from his article last year on 8 Patterns To Help You Destroy Massive View Controllers, @khanlou has recently released a new article containing a lot of great tips about how to move some of the responsibilities that are somewhat related to views, out of the view controllers and into the views themselves.
Sticking with the theme of tackling large view controllers, this article from @ctietze is in a similar vein, but this time takes a look how to reduce the problem of large UITableViewControllers by factoring out some of the content and configuration into additional helper classes.
In this weeks post I build on the knowledge from my Swift Optionals post by taking a look at how we can use Optional Chaining to conditionally access properties and methods whilst simultaneously making our code cleaner and easier to read.
With the release of Swift, we’re already starting to see some interesting things surface. This week saw IBM introduce the IBM Swift Sandbox, a Docker container running on their own cloud servers that provides a fully executable Swift REPL, all accessible from your browser.
One of the big surprises of last weeks release was the inclusion of a new Swift Package Manager. Although in it’s early stages, the initial implementation been worked on by both @mxcl and @mattt (amongst others) and could eventually provide both seamless integration with Xcode and a long-term replacement for both Cocopods and Carthage. On this theme, there has already been some interesting discussions within the Cocopods team here and here which are worth reading.
Swift Summit Videos
Looks like my Christmas viewing is getting jam-packed. This week I came across the archive of videos from Swift Summit which was held earlier this year. I wasn’t able to attend the summit myself, but it’s great to be able to catch up on the talks that I missed. There’s a lot to choose from, so sit back, relax, and enjoy.
Having a solid understanding of Swift protocols and the idea of Protocol Oriented Programming is critical these days. In this talk @gregheo dives into why we would want to use protocols, what we should include in them and looks at the wide variety of protocols from the Swift Standard Library to see if there is anything else we can learn.
I wanted to sign off today with a couple of things. First is this video which gives a very interesting view on the evolution of the Swift code repository from its inception back in 2010. The video is made using a tool called gource if you want to check it out for yourself. It’s easily installed via Homebrew and pretty interesting to run on your own repositories.