Do You Even Swift?
Just some thoughts on how I came to go all in learning Swift at home while still advocating Objective-C as our primary language in the office.
When Apple annouced Swift at WWDC I was super excited at the chance to be in on the ground floor of a new and modern language, one that I expect to become widespread and long lived. I could fastrack to greybeard-dom and be one of the crusty old devs that was there at the beginning1. But of course there were projects to get done and old apps to support. Swift is sold as easy to integrate into existing projects and easy to interoperate with Objective-C, and it is in many respects, but the few tries I gave it brought frustration in the shape of Xcode crashes, debugger bugginess, confusing compiler errors and the additional cognative load that comes with juggling two languages at once. So Objective-C kept its place and while I toyed with the idea of writng a class or two in Swift I never bothered, it didn’t seem worth the hassle right now and I wasn’t missing out on much.
Fast forward a few months and, through no endevour of my own, I find myself in the middle of a large Swift codebase, helping out on the team that’s writing an app that will be responsible for selling flights and checking in passangers for one of the worlds largest airlines. I’ve been working full time with Swift for about a month now and I’ve been pleasantly surprised at how productive I’ve been with it. There are still a whole lot of Xcode frustrations for sure, but not so many more than any developer who jumped into Storyboards or Auto-layout when they first emerged will be accustomed to and obviously each release should improve the situation.
It only took about a week before Objecive-C became the wrong looking language, and the couple of side projects I work on at home have already been converted to Swift. I really like the language and I’m excited about it again just as I was when it was first announced and I expect most code snippets on this blog to be Swift from now on. But the interest in the new language, and my desire to use it personally still wouldn’t change my mind on the decision I made last summer, the next big project for a client that I choose the language on will not be Swift. The decision making process here is simple2 Swift is young and evolving rapidly and during this Swift version 1.1 project Swift version 1.2 appeared. For science I downloaded the Xcode beta and opened up the project - no surprises for guessing - it doesn’t build anymore.
There is a handy Edit > Convert > To Latest Swift menu option in Xcode, but the number of build errors before and after was roughly the same (interestingly you can run it multiple times and get a few more to go away) and while some of the remaining ones are simple renames and a lot of changing as to as! (why the tool couldn’t find all of these I don’t understand) there are a few that will require a bit more investigation.
Maybe there’s only an hour in fixing up all these build errors, but it would warrant another round of testing and I suspect at least one or two additional bugs would emerge. Not a huge problem for this particular project which will be actively worked on for the foreseeable future, when each Swift version can be migrated to in turn, but for the kinds of projects I often work on there could be a couple of years between releases. In that time Swift will probably change several times, perhaps in significant ways, and we’d likely be required to use latest Xcode versions to submit to the App Store for even the most minor bug fix. Swift could be the thing that turns an essential bug fix release from a simple 1 day turnaround to a weeks long nightmare.