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 newsletter! This week has been a good week for me. I’ve had a couple of days off including a visit to Legoland (the UK home of all things Lego) with the family along with the great news that work are actually going to let me attend iOSDevUK in September! I’m super excited to be attending in September as it’ll be my first iOS-oriented conference so if you are going to be there be sure to come and say ‘Hi’!
In the mean time it’s been a busy week in the community so let’s take a look at this weeks links.
It’s been a while coming but this week saw the announcement by @tkremenek on the Swift.org blog about the release process for Swift 3.0. The short version is that the Swift 3.0 release is unsurprisingly not going to be source compatible with Swift 2.2 – meaning it’s going to break a bunch of things – but will be the first time that the Swift Package Manager has been formally included within the release. The general release process is going to start on May 12th, with developer previews available every 4 – 6 weeks working up to a release later in the year. It’s existing times and hopefully the last time we’ll be suffering code breakages for a while.
Another announcement this week was this one from Apple. As of June 1st, all apps that are submitted to the app-store, must support IPv6 only networking. For most apps, this shouldn’t have too much of a problem (NSURLSession and CFNetwork both support this out of the box) but but if you are using IPv4 specific APIs or hard-coded IPv4 addresses (say for checking reachability to 0.0.0.0) now is the time to get your code base in order. A good WWDC video explaining some of the changes and how to test your app can be found here.
We’ve all had those nightmare projects. In this article, @rayvinly looks at the relationships and communication between client, designer and developer and looks at the contributing reasons why mobile development projects commonly fail. It’s a well-written article with some good tips and is one that may be all too familiar.
“There is still no consensus on the pixel density at which mobile screens should be designed”. In this article, @kurtvarner puts forward 7 reasons why we should be designing our mobile interfaces at x1 (rather than x2, x3 or any other resolution for that matter). It’s a pretty compelling argument, so if you aren’t designing at x1, maybe you should think again.
I’ve been holding off linking to theses articles until the series was complete. If you haven’t seen them already, @donnfelker has been writing a great series of articles on the SOLID Design Principles. It’s pitched at Android development but it’s equally applicable to iOS or any language requiring object-oriented design for that matter and is a series you should definitely read if you’re not already familiar with SOLID. For convenience, links to all the articles in the series are below:
- Single Responsibility Principle
- Open / Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
If you’ve been following the Swift Evolution mailing lists recently you’ll have noticed the huge number of changes and proposals that have been under review. (So much so that I’ve no idea how people are keeping up). Anyway, @ericasadun has written a great summary of the latest batch of changes.
I managed to find time to write another article this week, this time looking at Swift Assertions. There are five available in Swift and can be useful tools for debugging your applications both during development and in production. Take a look and add your views at the link below or drop me a message on twitter.
After including an article in last weeks newsletter on Swift compilation times, @RobertGummesson has written a great follow-up piece including a tool to surface these compilation times in Xcode and a few surprising Swift statements that appear to contribute significantly to build times.
Honestly, I always find recursion a bit mind bending. This however, is a great article from @uraimo that looks at how to avoid those nasty stack overflow issues by re-writing your normal recursive code using tail recursion and trampolines.
At their core, all animation is interpolation – simple values, changing over time. This library from @marmelroy takes that idea to the next logical level by connect these interpolated animations to associated gestures. It opens up some interesting possibilities.
Back in Issue 28 I linked to a talk by @wangshengjia in which he outlined an idea for a declarative mechanism for constructing and reconfiguring your apps UI, an idea I really liked. Since then, he’s been hard at work with the result being LeeGo, a lightweight Swift framework for allowing you to decouple and modularise your UI components into building blocks much like Lego. When I’ve got some time, I’ll definitely be playing with this.
I really enjoyed this talk from @jeffburg. In it, he imparts some of his knowledge, experience and lessons learnt from his last few years of teaching Swift and iOS development to students with little or no programming knowledge. For me, I got a lot of value from the talk and some great tips that I’ll be trying to incorporate into my articles on the website in future. Gets a big thumbs up from me ?
I was trying to explain how complicated this was to my parents this week. I’m not sure they got the full implications of it but there is no getting away from it, the team at @spacex are just nailing it. After the first successful water landing last month, this is a seriously impressive learning curve and a huge congratulations to all of them! (Checkout around 28 minutes in if you’re pushed for time).