Lack of ABI stability, slow compile times, poor Xcode support, and more hold Swift back
For several years after the iOS SDK was announced, developers were flocking to Objective-C as they sought to get their slice of the app development gold rush. But those times are gone: Swift has been with us for over three years now, and has largely pushed its older sibling from the limelight.
Objective-C – once the rising star of the app development world – has started to become a second-class citizen in the Apple ecosystem. Yes, it might occasionally get dusted off for a slide or two at WWDC, but the majority of conference talks worldwide are in Swift, Apple is pushing Swift hard in the education space, and major language features come to Swift first.
But if you’re still using Objective-C, you’re not alone – many other developers still prefer Objective-C to Swift, and with good reasons. I got in touch with some Objective-C developers to ask what’s holding them back, whether they feel Objective-C development has become stigmatized, and more – here’s what they had to say…
Note: Views expressed here are personal and may not represent the views of their employers; people are listed in the order they responded; some answers were edited for length.
Steve Troughton-Smith: There are a variety of reasons why I avoid Swift. First and foremost, I don't enjoy using it – I find the language much more difficult to read and parse than ObjC, especially with if-let variable assignment in loops and switch statements (which is chaotically overused in Apple's body of sample code, like for ARKit). I am no newcomer to different languages, having written things for all kinds of platforms, and Swift is definitely at the extreme low end of the legibility spectrum for me.
I'm not yet convinced of Apple's level of participation in the language — four years on, Swift is not used for important pieces of iOS, OS or frameworks (I maintain a running list of Swift apps from Apple on Twitter, and macOS is definitely less shy about adopting it for new features than iOS). I understand why that is the case (ABI stability, etc), but if Apple's not using it for everything I don't see why I need to be beta-testing on their behalf. I lose nothing from waiting until Swift is 'ready', and I gain all the benefits of Objective-C in the meantime.
I'm fully of the belief that just because Apple builds something and says it's the way forward doesn't mean it's the right choice
Anecdotally I had heard, for the first few years, that Apple was as divided on Swift as anybody — Apple is, of course, a massive body of ObjC developers and Swift was as much a surprise for many of them as it was for us. And I'm fully of the belief that just because Apple builds something and says it's the way forward doesn't mean it's the right choice — we've seen a whole bunch of missteps (discoveryd, iOS 7, iOS 8) or 'mehs' (macOS, Touch Bar) from Apple in the past several years, and it certainly doesn't hurt to wait and see how it pans out.
Michael Lauer: I don’t see the incentive. I’m extremely productive in Objective-C and I view the language as very elegant, concise, and expressive. If there were first-class (async) concurrency in Swift, I’d jump in a minute. In contrast, I hear about slow compilation times, massive duplication of runtime libraries, and I have yet to see a significant runtime performance improvement.
Dan Leivers: For prototypes or very small projects I’ll use Objective-C, purely for ease of updating after a significant period of time has passed (which is often likely with those types of clients). I also maintain Objective-C apps for a number of clients and there’s simply no time (or reason to switch them to Swift). Cutting new code for those projects in Swift often ends up with the same scenario mentioned for prototypes.
Peter Molnar: To be honest before version 3.0 the main roadblock for me was the missing source code compatibility, and even after 4.0 I am still waiting for ABI stability. I think that’s the only one issue left, and personally I feel that this is less important for me if the source compatibility works.
Todd Thomas: Xcode support for Swift seems laughable. From stupid long compile times for large projects to crappy refactoring and debugging. Tweetbot for Mac is a fairly sizable project and it takes 44 seconds to compile it on a 2012 Retina MBP. That includes 1 framework, 1 library and the app itself. Also, Swift isn’t ABI stable yet – when I don’t need to ship the Swift libs with my app I'll be more likely to start slowly converting some parts of the app to Swift.
Our build times are ~6 hours for a full clean build, and adding to that would not be great.
Ian McDowell: We have a ton of shared C++ code for our business logic, which is shared with Windows & Android. We write our UI in native UIKit/AppKit in Objective-C, and have a lot of Objective-C++ files to bridge between the two languages. As of yet, we have not adopted Swift for much, aside from a few scripts & internal tools. Hearing from other teams using Swift, the compile times are slower than Objective-C/C++.
We have hundreds of Xcode projects, all eventually compiled into a giant static library that is linked into each of the app binaries. This is done to reduce app launch times. Our build times are ~6 hours for a full clean build, and adding to that would not be great.
Simon Wolf: My primary coding project is for a client and it’s a large codebase which has evolved over several years. Whilst I’ll introduce some Swift into it, because a lot of the work I do involves editing the existing code it prevents me from using too much Swift.
As a consultant I am also aware that each time there is a new major version of Swift I’d either have to charge them to update what they see (correctly!) as working code or take the him myself. Neither are ideal propositions.
Marco Arment: For me, it’s not a judgment about Swift itself, but a pragmatic decision: I’m already an expert in Objective-C and extremely productive while using it, and the benefits of switching to Swift aren’t compelling enough to overcome the costs for me.
Marcel Weiher: A lot of my best work includes heavy metaprogramming and the judicious mixing of the C parts of Objective-C with the dynamic messaging parts. All that gets more difficult, so much that you couldn’t, for example, write CoreData in Swift. Also churn: I just tried to find some sample code for Apple Pencil. All of it was Swift. None of it compiles today.
Steve Troughton-Smith: A little? It's deeply unpopular to use ObjC or say you like ObjC over Swift. Swift has a truly massive hype train, and you definitely don't want to stand in the way of it.
Like anything that creates passionate and fully-bought-in fans, there's no point engaging in reasoned discussion. Swift users are just as (and more) aware of its downsides as I am, but they're happy to make that compromise because of the perceived benefits. I am not, and don't perceive the same benefits.
Michael Lauer: Absolutely. I feel like I constantly must defend myself for "being a dinosaur".
I believe Amy Worrall’s talk at iOSDevUK was in Objective-C and there was some unrest from the audience which seemed to be people not understanding it.
Dan Leivers: Definitely, there’s a drive for the new and shiny. Which is perhaps how many of the iOS community ended up there in the first place, so it’s not entirely unsurprising there’s still a push for the bleeding edge. I believe Amy Worrall’s talk at iOSDevUK was in Objective-C and there was some unrest from the audience which seemed to be people not understanding it.
Peter Molnar: I have this feeling more when I am reading the job titles and job descriptions, not necessarily in the social media. Everyone is looking for Senior Swift developers now
Todd Thomas: I don’t worry too much about it. The app should speak for itself. If it is good the users won’t care what it is written in.
Ian McDowell: I have felt some stigma, but not a lot, about still using Objective-C. I use Swift for all of my personal projects and love it, and understand the reasons we don’t use it here at work.
Simon Wolf: A little but because I don’t believe that Swift is bad and Objective-C is the one true Cocoa language I tend not avoid heated arguments about the pros and cons of Swift. I also haven’t seen people being too rude about Objective-C developers but as a Mac developer I tend to be on the edges of the iOS community anyway which is probably where most of the conflict is. I don’t think that Mac developers are as keen to use the latest and greatest. We’re still battling NSCell.
Marco Arment: This is already starting, but every transition happens this way. Objective-C developers made fun of Carbon developers. It’s just a natural side effect whenever your language isn’t the currently considered “language of progress” anymore, but you’re still using it for pragmatic reasons. As a PHP developer on the web side, I’m accustomed to this.
Steve Troughton-Smith: Fully excluded; a Swift-only conference is one that has nothing for me. I don't want to have to care about Swift best practices or design patterns now before the language is fully formed and before Apple is using it at scale. I don't want to collate a dozen community-led design patterns, I want to do what Apple does.
A Swift-only conference is one that has nothing for me.
Knowing that Swift is the one true 'future' for Apple development has done a lot to push me away from wanting to make apps outright; the one-two punch of the iOS 7 UI with the Swift transition certainly made me feel like this isn't a platform I want to develop for anymore.
Michael Lauer: It’s sad. Of course I can translate everything I see, but it’s more effort than before. And I refuse to submit talks to any conference where they demand examples in Swift. Thankfully there are still conferences for the “rest of us.”
Dan Leivers: At least they’re mostly consistent!
Peter Molnar: I think it’s the part of the evolution, but it is true – there is not too much life around Objective-C. Swift is new and thanks to it continuously changing there is a lot to talk about, and obviously a lot will also be obsolete by tomorrow.
Todd Thomas: I guess if you want to be forward looking conferences should probably use Swift. I don’t mind personally but also don’t pay a huge amount of attention to conferences either.
Ian McDowell: I feel great, it’s the future!
Simon Wolf: I don’t mind it. I realize that Swift is the new shiny thing and, since I know Swift well enough to understand it, it really doesn’t worry me. Had I buried my head in the sand and not bothered to learn Swift I may feel left out but I don’t think that approach is conducive to being a good developer.
Marco Arment: It doesn’t bother me. Most conference organizers and attendees stay closer to the bleeding edge than I do, so of course they should use Swift. Translating Swift snippets to Objective-C from conferences, tutorials, and Stack Overflow is just one of the costs of continuing to use Objective-C today, and so far, that hasn’t proven to be especially burdensome. Over time, that burden will increase.
Marcel Weiher: I have to admit I find a lot of the Swift talks very superficial and often laughably ill-informed, so I guess I feel disappointment. I know this sounds harsh, and there are obviously exceptions, but OMG.
Steve Troughton-Smith: Swift was absolutely catastrophic for Objective-C development; for any new APIs or features I no longer have sample code, WWDC slides, tutorials, GitHub or StackOverflow. Whatever about StackOverflow millennial jokes, but losing access to all of this context and knowledge is devastating. On the plus side, the ObjC language itself has gained a bunch of quality of life/syntactic sugar features to help it interop with Swift better, and all of those have been fantastic.
Swift was absolutely catastrophic for Objective-C development.
I really resent the fact that ObjC has to die to make Swift live — if the two languages could have lived independently of each other, everything would be fine for developers like me, who could just pick the language most appropriate for the task at hand. The passionate, massive movement behind Swift made that all but impossible, as well as Apple's cessation of creating ObjC resources for developers.
Michael Lauer: Mostly hindered. The benefits “we” got thanks to Swift were lightweight generics and nullability, but that’s about it. I can only dream about what could have been Objective-C if there was the same manpower behind it.
Dan Leivers: I think it’s initially helped but I can’t help feel it’s mostly being put on the back burner now.
Todd Thomas: I think it has helped. They added many useful things to the language for Swift so we can’t complain about that.
Ian McDowell: Objective-C has gotten a few nice features from Swift, including the
@available syntax and nullability specifiers. It’s a stable language and I haven't expected it to change any more than it has.
Unwrapping in Swift can be a pain but it has helped me adopt better practices in Objective-C.
Simon Wolf: It’s helped in so far as there are some changes and improvements to Objective-C which are a result of Swift. In addition, writing a little Swift has encouraged me to look as some of my Objective-C coding practices and I’m less inclined to let nil objects sweep things under the carpets. Unwrapping in Swift can be a pain but it has helped me adopt better practices in Objective-C.
Marco Arment: Swift has effectively stopped development of Objective-C as a language. That’s neither surprising nor unreasonable, but fortunately, Objective-C is pretty mature. The few years before Swift’s introduction brought a lot of improvements that should keep Objective-C usable until most of us move to Swift.
Marcel Weiher: Obviously hindered, but Objective-C is OK for what it is and really needs a bullet in the head more than further development!
What’s more surprising and somewhat disturbing is how many obvious defects in the libraries and “preferred coding styles” that would have been trivial to fix without introducing a whole new language weren’t until Swift arrived – and are now attributed to Swift. It’s almost as if these improvements were held back in order to make Swift look good, though I am pretty sure that’s not how it happened.
However, the biggest negative impact will be that it will most likely prevent the development of successor that’s an actual improvement. We really have enough information to build such a beast now, and Apple ignored just about all of it. And that’s a crime.
Along with all the questions above I also asked how long people had been using Objective-C, because I think it’s fair to say that familiarity with a language is always going to be important when choosing to stay or move.
It shouldn’t come as a surprise to hear that most people said they’d been using Objective-C either immediately after the iPhone SDK was first launched or shortly after, with a couple having used it for well over ten years and one for 27 – yes, twenty seven – years. I should add that one responder said they had started Objective-C relatively recently, so perhaps there’s still life in the old dog yet.
One more thing: last year I wrote a book called Objective-C for Swift Developers, and in the introduction I included a section titled “Do I love Objective-C?” Here’s what I wrote in there:
When I read through the first complete draft of this book, I thought to myself, “wow, this reads like the Snark’s Guide to Objective-C,” because it felt like almost every chapter complained about something.
As a result, I spent some time editing the book to make it a little more upbeat – not because I’m trying to present things to you in an artificial light, but because I genuinely loved working with Objective-C. I switched to Swift the day it was announced, and had a Swift app live on the App Store on the first day it was possible to do so. As a result, in many respects Objective- C only seems bad because Swift is so much better – I’ve been working with Swift so long that going back to Objective-C feels a bit like returning to your rural home town for Christmas when you’re used to living in a big city.
I can’t tell whether I loved Objective-C because I had Stockholm syndrome, or whether it was because Apple’s APIs are just so darned powerful. Regardless, I think it’s important you realize that some amazing software has been built with Objective-C and many people love it just as much today as they always have.
When you find things in this book that make you cringe, be gentle: it’s an old language, it’s come a long way, and it has served us very well. At the very least, it deserves dignity in retirement!
Thank you to Steve Troughton-Smith, Michael Lauer, Dan Leivers, Peter Molnar, Todd Thomas, Ian McDowell, Simon Wolf, Marco Arment, and Marcel Weiher for taking the time to contribute their views to this article.
Now it’s over to you – if you still prefer using Objective-C over Swift, let me know on Twitter!
SPONSORED Instabug helps you identify and resolve severe crashes quickly. You can retrace in-app events and know exactly which line of code caused the crash along with environment details, network logs, repro steps, and the session profiler. Ask more questions or keep users up-to-date with in-app replies straight from your dashboard. Instabug takes data privacy seriously, so no one sees your data but you! See more detailed features comparison and try Instabug's crash reporting SDK for free.
The biggest ever Hacking with Swift sale is now on, letting you save 50% on all books and bundles. Learn something new with Swift and enjoy great savings while the sale lasts!
Paul Hudson is the creator of Hacking with Swift, the most comprehensive series of Swift books in the world. He's also the editor of Swift Developer News, the maintainer of the Swift Knowledge Base, and a speaker at Swift events around the world. If you're curious you can learn more here.