Issue 486  December 11th 2020

This is a fascinating story from McLaren Stanley about a rewrite of the Uber app in the early days of Swift. If you’ve not yet read it, go and give it a look now. I promise it’s worth your time.

It’s easy to forget how rough the first couple of years of Swift development were, and how early adoption had a real cost. That cost might have been manageable in a small app, but this story is a rarely shared insight into what it was like at a big company that decided to go all-in so early.

Rewriting an app when a new technology comes along is so tempting. The idea of being able to remove all those imperfect decisions, and getting a “clean start” is intoxicating. Add the allure of the brand new technology into the mix, and it can be almost impossible to resist. Of course, the path is rarely smooth. New technologies often demo well but also have really spiky edges that hurt when you run into them. You’re also just as likely to make a whole new set of bad decisions as you fix the last set. 😬

We’re fortunate in software development that we’re able to go back and tweak the things we’ve built. We’re able to improve what we already have at the same time as shipping new features. It’s a rare privilege that’s not afforded to many industries. You can’t tweak a novel after it’s been published, or a building after construction is finished.

Yes, it can be hard to make large architectural changes incrementally, but is it harder than making large architectural changes while also adopting a new language like Swift or a UI framework like SwiftUI?

The Swift transition is mostly done by now, and I expect the vast majority of you are now writing most of your new code in Swift. The SwiftUI transition period is still in full swing though, and once that’s done, there’ll surely be another tempting opportunity to rewrite! We’re lucky with technologies like Swift and SwiftUI that Apple pays attention to interoperability, it’s a great deterrent against the lure of the rewrite. 😅

That said, you should also be careful not to fall too far behind. We’re now 18 months into SwiftUI, and if you’ve shipped any part of a real app using it, you’re ahead of the curve. If you’ve not yet had at least a little play with it in a demo/test app, you’re probably on the edge of lagging behind. Like everything in software development, it’s a balance, and there’s no right answer. Just try and avoid being a zealot, or a curmudgeon. Stories like this are also a good reminder that being “pure” anything isn’t something to strive for, in my opinion.

The story McLaren tells worked out in the end, but he also refers to several people burning out. I’m glad they ended up in a good place, but you should treat this as a cautionary tale. It’s not the only time I’ve heard stories like this, and I’ve even participated in one or two over the years, although the scale of mine are much smaller.

Thanks for sharing McLaren!

UPDATE: Several people have messaged/tweeted me since yesterday about this sentence:

If you’ve not yet had at least a little play with it in a demo/test app, you’re probably on the edge of lagging behind.

I should not have said “lagging behind”, and I’m sorry I wrote it. My intention was not to judge or make anyone feel bad, but I did, and I’m sorry. I do think that it’s a good idea to have had a play with SwiftUI in some context, but you’re definitely not lagging behind if you haven’t.

Dave Verwer