Issue 227

4^th December 2015

Written by Dave Verwer

Comment

So, it was shaping up to be a quiet week until yesterday! Unless you’ve been locked in a windowless, soundproof room for the last 36 hours you’ll already be aware that Swift was released as open source, right on schedule. Everything is up on GitHub and already people are tackling the hard problems. 🙄

I’m sure the madness that is the current set of PRs will calm down over the next few days (or weeks) and the proper work will start. But instead of focusing on that, let’s talk about the release itself.

I’m extremely impressed with how Apple have approached releasing Swift into the community. When it was announced that there would be an open source release, there was very little detail on what that actually meant. It could have been anything from a simple, occasional source drop to development done in public. What did we get? Well, pretty much everything we could have hoped for. This truly is an open development process now. Not just in terms of the source code, but in terms of everything that goes along with it, including discussion of plans and features for future releases.

To me, the source code itself is the least interesting part of the release (don’t forget that Objective-C was open source too!). I really have no need to peruse the depths of the Swift implementation. I’m not a compiler engineer and I doubt that the vast majority of iOS/Mac developers will ever end up deep inside the Swift implementation. What’s exciting to me is all of the peripheral information, and tools that accompanied the release, and even more important than that the fact that the Swift team inside Apple has managed to effect this kind of change.

There’s links to various interesting bits of the release below, but I’ll end here by saying congratulations to all of the team who have been involved in this project. It can’t have been easy and you’ve all done a wonderful job with it. Bravo.

This week’s issue is going to be a little lighter on the other links due to the amount of information on the Swift open source release. Back to normal next week though!

Dave Verwer

Sponsored Link

Save valuable development time with high-quality, feature-packed grids, charts, and gauges that add animated visualizations to your universal iOS apps. Xuni iOS includes controls and samples with source for Objective-C and Swift development with Xcode. Download a free trial of Xuni iOS to get started.

News

So here it is, Merry Christmas! The new home of the open source Swift project. Obviously you’ve got the GitHub repositories but you’ve also got binary distributions here for both Mac OS and also Linux. Instructions on how to set up and get it running, contributor information and even API design guidelines. It’s also worth reading this interview with Craig Federighi which has more detail on their plans.

This was a completely unexpected inclusion in yesterday’s announcements. It’s at the core of all of the work for this Swift release and even gets used in the Getting Started document.

It’s very early days for this tool and it’s definitely not (yet) a replacement for CocoaPods or Carthage, but I see the start of great plans here. Once it grows and potentially gets integrated into Xcode I can see that this could easily become the primary package management solution for all Swift development.

The final huge piece of news that accompanied yesterday’s release was that there is a Swift implementation of Foundation in progress and they are aiming for parity with Obj-C Foundation for the release of Swift 3. The goals of this are mainly focused around portability and cleaning up some of the baggage of Foundation such as new naming conventions, the removal of NS prefixes, that kind of thing.

I am very curious about Apple’s plans for portability. There’s always a reason for changes and I wonder what announcements we might see at WWDC 2016 on the subject of server side Swift? Maybe CloudKit + Swift on the server? Maybe something even more adventurous?

Tools

Crayons is an Xcode plugin from Fabio Ritrovato which exposes to Interface Builder a set of methods that return colours. Effectively this means you can easily pick from colours in your code directly from the attributes inspector. The biggest weakness here of course is that any changes to the colour in your code won’t be automatically updated in IB, but that won’t be solved until IB interacts with code better.

Ever tried to match an exact colour for an iOS navigation bar with transparency turned on? It’s frustrating, but this tool by Ivan Rublev might solve the issue. It only works well for lighter colours but could still save you some time.

Code

Deep linking and Spotlight search in iOS 9 are a perfect opportunity for an app like Flickr to really shine. This article not only goes into the basic implementation of those features but also discusses considerations around privacy and keeping data up to date. Definitely worth a read.

Soroush Khanlou with a follow on from his article on combatting massive view controllers last year. This post talks about moving as much view logic as possible out of the controller and into the view. I really like this approach.

Size Classes might seem easy at first but there’s a load of edge cases which you’ll need to be careful with, especially around popovers. Keith Harrison has a great article here on how to cope with some of the problems you’ll come across when trying to implement this properly.

iOS has wonderful support for accessibility, both in the standard operating system and also in the developer APIs. It’s always a worry when a framework like React Native is released, whether that support will still be available. Luckily, it looks like it was something very much on their mind when developing it.

Sponsored Jobs

We’re building the future of the internet, and we need you.

Challenge the realms of the possible. Sky Mobile Technology

And finally...

Love it 😊