Often, readers will ask me why all my blog technical posts are in Objective-C, and not Swift. I don’t write blog posts in Swift because I don’t write code in Swift. There are three big reasons for that.
Swift is not production-ready
Trying to use Swift in any professional capacity is a joke. A very cruel joke. The “tooling” is terrible: compilation speed has been abysmal, and SourceKit spent the better part of the year as a punchline.
Last year, at WWDC 2014, Apple claimed that changes to Swift over the course of the year would probably break source compatibility, but that binary compatibility would be maintained (Apple dev forums). That’s now rumored to be a goal for WWDC 2015:
With iOS 9 and OS X 10.11, we are told that this will change: Swift is planned to reach what is known as “Application Binary Interface (ABI) stability,” and its code libraries will therefore be pre-installed within the new iOS and Mac operating systems.
Even if they could have maintained binary compatibility all year, the source changes will break old versions of your code from compiling. This means awesome tools like git-bisect are completely useless. Being able to hop to past versions of your app is part of the value of version control and writing code in Swift ruins it.
I understand and accept the “release early, release often” philosophy, and I’m glad the Swift team has embraced it. It’s good to polish Swift in public rather than in private. However, for someone who maintains their livelihood through code, writing that code in such a fledgling language is dangerous. It’s never been smart to program using the bleeding-edge technologies. How many times do we have to be bitten before we become a little shy?
Swift is complicated
Swift is not a simple language. This Quora answer by Rob Rix is bound to become an instant classic. I don’t even understand how some of these bullet points can be real.
enumcases act like functions, but are not functions.
…- The rules for overriding a superclass’ init are Byzantine to the point of impossibility.
At 10:05 in Build Phase 82, the hosts discuss methods versus computed, lazy, and stored properties. There are so many little rules to know about!
How do you choose whether to use a struct or a class? Well, I hope you’re ready to memorize a bunch of arcane rules for how these two (nearly identical!) things work.
There’s so much new stuff to learn about. But it’s not the good kind of learning, where you expand your mind and discover new ways of thinking and working. It’s rote memorization of the six new inscrutable ways to make readonly properties. Learning that stuff won’t make you a better programmer or thinker, it’ll make you better at working around Swift.
Objective-C has plenty of complexity in it, given that it’s a superset of C. But we had a chance to totally change that, and we dropped the ball. Designing languages isn’t easy, especially languages that are going to be used widely in practice. But Swift tries to be great at both functional and object-oriented programming, and ultimately, becomes awkward at both.
I’m not good at Swift
The final big reason I don’t write Swift is that I don’t think I can write good Swift yet. I’m not really convinced that any of us can. Our job is to deliver timely, high-quality software, and there’s tons of experience doing that in Objective-C.
Don’t get me wrong: that doesn’t mean I don’t think I can write great Swift ever, or that it’s not worth learning. It’s just not worth shipping code in right now. I love reading the blog posts, with people exploring and researching and trying to understand all the new things we can make. One day I hope I’ll understand transducers and lenses and functors and closed groups. Ultimately though, for the near- to mid-term future, I can ship much better code with my Objective-C knowledge, and anything I do in Swift will be fundamentally experimental.
It’ll be interesting to see what next week’s announcements bring us. I’d love to eat my words and see some new stuff in Swift that is worth all the pain. My original plan was that I’d wait a year before writing any Swift, and I hope that I don’t have to wait any longer. My suspicion, though, is that we’ll see a more stable Xcode 7, and Swift 2.0, which will bring us a little cleaned-up syntax and not much else.
Post-WWDC update: Protocol extensions are so so so cool, but ultimately, I think my stance will stay the same. Via Michael Tsai, iOS 9 still doesn’t have ABI compatibility. My new plan is that once Swift is source compatible with previous versions, the next new app I write after that will be all Swift. I don’t want my code to break when I go back in git, and I don’t want to deal with the context switching of having Objective-C and Swift in one app.
