Within two weeks of the Swift announcement, clients were asking me if I thought we should be writing new apps in Swift.  The answer, and I hope this doesn’t surprise you, is a resounding NO!

Swift needs time to stabilize.  We need to write plenty of bug reports and feedback on it.  As a community, we need to learn where it’s limits are and establish a new set of best practices for it.  I’m not shipping code on a platform that’s still defining it’s syntax.

As soon as I make those points, everyone nods and agrees.  “Hm,” they say, “we hadn’t realized that it’s still in flux.”

It’s not just languages that have this issue.  A version one of any API as almost moving a little bit.  Sure, the method calls might stay the same, but the behaviour can change subtly underneath you as bugs are fixed and edge cases are recognized. [1]

I do my damnedest to avoid shipping code that relies on new APIs [2]. I don’t like shipping code when I don’t fully trust the libraries beneath it yet.

That said, of course I’m working on side projects with Swift and all the new APIs that catch my attention.  Though I’m conservative in what I ship, I’m far more liberal in what I code.

I like my side projects to push into the new and shiny.  In the words of The Friz: “Take chances, make mistakes, and get messy!”

There can be a fine line between being conservative in your views and being regressive.  Make sure you’re pushing back for the right reasons.  Colour outside the lines when you can.

Footnotes

[1] It’s easier to recognize when your compile breaks as the language updates, but shifting APIs can break your app too.

[2] Unless the goal is to get featured in the App Store by using the newest APIs.  That’s certainly not a bad goal.