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.
Hi, I hope you’ve had a great week!
So this week, we’ve got a bit more clarity with regards to the way ahead with Swift 3.0 and beyond.
The first preview branch of Swift 3.0 has been cut, and yesterday saw @clattner_llvm announcing via email and an update to the top-level README.md file in the Swift repo, the updated goals and way ahead for Swift 3.0.
For many, the major point, (and potential disappointment) of the announcement, will be that Swift 3.0 will NOT be achieving the releases goal of ABI stability.
Although this is a shame (and means we are likely to still see breaking code changes in future), you can probably see from the list in the README file that there have already been a huge number of changes implemented for the Swift 3.0 with a whole load more that may yet make it into the release if implemented in time.
For me, I’m somewhat philosophical about this. Although I’m not looking forward to more breaking code changes in the future, I do think that collectively the changes that have been implemented so far for Swift 3.0 are a big improvement that both clean up the language and make it more consistent.
Whatever your views, whether disappointed or not, I still think that Swift, even now, is an outstanding language with a very very bright future ahead of it and personally, I’m really enjoying following it on that journey.
It’s taken four and a half years, 20K commits and the dedication of hundreds of developers but this week saw CocoaPods finally reach version 1.0!
A huge congratulations to @alloy, @segiddins, @orta and the rest of the @cocoapods team along with the hundreds of developers and sponsors who have contributed to making CocoaPods such an invaluable resource!
If you’ve not read it already, make sure you check out both the 1.0 release of the associated desktop app, as well as the 1.0 Migration Guide as there are a few changes with this release that you need to watch out for.
As you know, the journey for your app is nowhere near over at the point it hits the app store. There’s the launch, the marketing, the promotion and the list goes on. The key thing though is to know whether all your efforts are actually moving the needle and for that we need analytics. In this article, the team at @transporter_app help with that by providing a crash course in the analytics that we all have available – those that are baked into iTunes Connect.
There has been a bit of a performance theme in articles I’ve included recently and this one is no exception. In this article, @benjaminencz provides some handy debugging tips as he dives into the bowels of UIKit to find out why adding a tint to a UIView containing a load of subviews is quite so bad for performance.
Whichever way you look at it, the transition to Swift 3.0 is going to be a little rocky. In this article, @ericasadun takes a look at the implications that Swift evolution proposal SE-0046 and it’s changes to methods signatures will have going forwards and how you can partition your Swift 2.2 and Swift 3.0 code leading up to the transition.
In this article, a follow-up to her Practical Protocol-Oriented Programming in Swift talk, @natashatherobot, provides a good example of how restructure your networking code using protocols so that you can actually test it.
Sometimes it’s good to drop down to the work directly with bits and bytes. In this, another great article from @xenadu02, he eschews JSON, protobuf and NSCoding and instead looks at how to directly encode and decode data into binary blobs.
With the development world having gone bot-crazy recently, I couldn’t resist including this article from @pvzig detailing how rise to world domination by building a Slack-bot using Heroku, SlackKit and Zewo.
I’ve seen several articles recently bemoaning the lack of the #warning directive in Swift and personally I agree, I found them highly useful when writing Objective-C. It was with interest then that I came across XcodeIssueGenerator, a tool from @soolwan and the team at @POSSIBLEmobile that could provide a viable alternative.
Working with stringly typed values such as when loading images, segues or storyboards has never been the most reliable of mechanisms providing ample opportunity to get things wrong. R.swift by @mac_cain13 all but eliminates this problem, examining the resources in your app and automatically generating a struct to map your app resources to Swift properties.
Setting up autolayout constraints in code has never been the easiest thing to do, especially when you throw in the stringly typing that is generally needed. Cartography by @dlx attempts to address this issue by providing a domain specific language to setup and manipulate Auto Layout constraints using declarative and strongly typed Swift.
Downloading and caching images from the web is a relatively common task in iOS and OS X applications. Kingfisher by @onevcat is a lightweight library written in pure Swift that provides both asynchronous download and in-built caching right out of the box.
I’m a big fan of the work that the team at Fabric have been doing recently. In this talk, @Javi walks through some of the decision making process and lessons learnt from writing the Fabric.app in Swift. It’s definitely worth watching.
I’ve not really played with GameplayKit other than the state machine aspects of it (which incidentally are pretty good in my experience). In this video, @jacknutting takes a look at four of the main features available within this framework and the the implications of taking component-based architectural approaches.
One of the huge benefits of open-source Swift has been the explosion in server-side frameworks allowing us to easily build both client-side and server-side applications using a single language. In this talk, @dantoml bravely tackles a live-coding presentation (typo’s, technical issues and all ?) and walks us through how to build a simple web API using Swift.