What to choose – Objective C or Swift ?

Deciding whether to use Objective-C or Swift for a project isn’t always a clear-cut decision; there are a number of factors to take into account every time you start a new project. We decided to tackle this topic because it’s one of the most common questions we hear from developers. Selecting the most appropriate language depends on project and team context, as well as preference and often, allegiance to a particular programming language.

Instead of waving our Objective-C or Swift flag, we take a look at all aspects of a project that point to one language over the other like project scope and scale, team composition, and technical considerations. This article even delves into choosing whether to switch languages for an in-progress project. As you read, keep in mind that no single point should dominate the decision. Your decision should come only after weighing the following factors as they apply to what you’re working on.

 

Your Experience with Objective-C vs Swift

The first thing to consider is your current experience with Objective-C and Swift. If you have equal experience with both programming languages, the language choice depends on a combination of factors we address below like third-party library compatibility, API support, team composition, and more.

If instead you have experience with one language and not the other, lean towards choosing the familiar language unless some project or team requirements overrule that. While using the language you’re least familiar with to create a production app will give you a chance to learn more about that language, it stands a good chance of amassing a significant amount of technical debt and delaying the app’s progress. You may find yourself in a situation like building a house on sand where no amount of restructuring can save it. In other words, the initial technical debt may leave you with no choice but to rewrite the app from scratch.

On the other hand, if you decide to create a prototype of your production app, do so in your most unfamiliar language. This approach gives you a chance to gain a familiarity with the new language. It will also benefit the production app because then you’ll have approached your app, its features, and its challenges from two angles of insight.

 

App Project Timeline, Scope, and Scale

First examine the specific requirements and constraints of your project. Your experience, the makeup of your team, and the size of your project will help you lean towards one language over the other.

App Timeline

Similar to what we mentioned above, writing production apps in an unfamiliar language runs the risk of amounting significant technical debt. This technical debt is paid in time and effort. If you have an aggressive timeline, you should lean towards the language in which you have more experience. If you don’t have more experience in one or the other, lean towards Swift (more on that later).

If you have a soft timeline with some wiggle room, you should consider writing in the language that makes you the most uncomfortable (for learning purposes). And if, by chance, you’re on one of those mythical projects with no set timeline, you should definitely choose the language that makes you the most uncomfortable. Projects with no set timelines are a luxury that won’t appear often in our careers and it’s a good idea to utilize this luxury to level up our game.

Team Composition

This is a topic that can be overlooked amid the more technical concerns, but shouldn’t be. You need to talk to your team before making any language decisions—even if you’re working in your own isolated area of the codebase. Make sure to revisit all the points as they apply to your team after you’ve applied them to yourself.

For example, do you work in a company that has a large number of sharp Objective-C developers with years of experience? It isn’t a good idea to start writing in Swift until they are all in on it. Even if you feel like you have good reasons and your arguments are predicated on everything in this article, you shouldn’t go your own way. Team friction can have disastrous consequences and in the end nobody wins. As long as you listen to your team members and follow a democratic approach to the decision process, you’ll be okay.

Project Scale

Small projects have the privilege of choosing whichever language makes the most sense because the overhead of converting Swift code as it changes versions will be minimal. Large projects, on the other hand, need to be very cautious about adopting Swift. Swift is immature and each new version (even minor versions) can entail the busy work of converting to new syntaxes and idioms. Nobody wants to see the build broken for a few days to a week each time a new Swift version comes out. Or even worse, being the developer who has to explain why it’s broken to management or comparable stakeholders.

Xcode provides us with tools to convert our Swift x code to Swift x+1. The tools, however, don’t catch everything. This isn’t a jab at the hard work the Xcode team puts into the conversion tools. Some of the language changes are just impossible to automatically convert without knowing the context behind the code.

 

Technical Considerations for Choosing Between Objective-C and Swift

Objective-C and Swift lend themselves to different technical advantages. Here are the factors you should consider after examining your app scope and team composition.

Tooling Support

The Xcode team has done a fantastic job upgrading the build process to support Swift. They’ve had to deal with implementing a complex language and supporting it working with a very different language (Objective-C). It comes as little surprise that the IDE itself lags behind and the tooling support for Swift is minimal. Sometimes you’ll be lucky to get syntax highlighting. Oftentimes you’ll go without autocomplete. And the refactoring tools flat out don’t work. If you’re someone who likes the robust support provided by modern IDEs, you should consider sticking with Objective-C or evaluating alternative IDEs. AppCode is the common alternative, but surely there’s someone who has a perfect setup for emacs and/or vim.

Language Runtime

The Objective-C runtime is more robust than the Swift runtime. Swift’s runtime isn’t close to catching up to Objective-C’s and it probably won’t for years to come. If you’re planning on writing code that will benefit from reflection and deep introspection of objects and types (usually reserved to powerful SDKs, but sometimes found in regular apps), Objective-C is a no-brainer. If you have no idea what that last sentence means, then chances are you’ll get by with Swift.

Code Stability

Swift is a safe programming language due to its strong typing system and error handling. If you follow idiomatic Swift and avoid ! operators in your code, you’re more or less guaranteed that your code accounts for all potential error cases. That doesn’t mean it catches everything. A memory leak from a retain cycle is one example of an error that is equally prevalent in Swift code as Objective-C. This is because Swift’s automatic reference counting system is unchanged.

Working with Foundation APIs

If the application you’re planning on making is going to primarily utilize foundation APIs (some examples are CoreFoundation, AVFoundation, and CoreAnimation), you should lean towards Objective-C. Swift provides some decent wrappers and makes the memory management a bit smoother, but these are still C APIs and C-based function calls that will fit more naturally into an Objective-C codebase.

Using C++ Code

Similar to Foundation APIs, using C++ libraries or building on top of a cross-platform C++ SDK will lend itself to an Objective-C project. You cannot import C++ into Swift files. To use Swift you would have to go through the tedious and often bug-ridden task of making Objective-C or Objective-C++ wrapper classes. This will require bridging and extra overhead each time you want to use another part of a C++ library. If you’re going to make use of C++, Objective-C is a better fit.

Operating System Version

Swift runs on iOS 7+, Mac OS 10.9+, and all versions of tvOS and watchOS. If the project needs to support anything below that, you have no choice but to use Objective-C.

Future-proofing

The most future-proof projects are ones written in Swift. In the past two years, Swift usage has expanded to being utilized for a third of all open source Cocoa projects. In the next four years, at that pace, it will be equal to Objective-C. Also the majority of all new tutorials and blogs are being written in Swift already. We believe that in 5-10 years there should be enough info on Swift to negate the need to understand Objective-C. That said, you’ll have plenty of time to convert your code before Objective-C goes away, so keep this as food for thought.

 

Bonus: Should You Switch to Swift for an Existing Objective-C Project?

Before we can answer this question, it’s important to understand what it means to use both Swift and Objective-C in a single project. This concept is called “bridging.” When you add a Swift file to an Objective-C project, Xcode will create a “bridging header file” for you. This is no different than your regular Objective-C headers except you only use it to import the Objective-C headers you want to expose to your Swift code. Xcode automatically creates a header that bridges all the Swift code to Objective-C. You can use this by adding an ModuleName-Swift.h line (e.g. Mail-Swift.h if you are working on a project named Mail) to the Objective-C files where you would like to use your Swift code.

The next thing to consider is the size of the project. A large project doesn’t lend itself well to bridging, because Objective-C code has leaky abstractions that make our Swift code less idiomatic. For example, if you have a protocol that extends NSObjectProtocol in order to use the Objective-C runtime on objects that implement the protocol, Swift classes that implement the protocol will have to inherit from NSObject or some other class in the NSObject hierarchy. This isn’t ideal because supporting the Objective-C runtime incurs four times the performance penalty for method calls ( because it uses dynamic dispatch instead of static). A small project can mix and match Objective-C code in a smoother way than a large project. In our experience, however, you’ll end up wanting to convert the remaining code to Swift over time and a small project will end up with a to-do list of Objective-C code you’ll want to convert to Swift.

Other considerations include team composition and project urgency. As noted earlier, if you’re working in a team setting, a consensus should be reached before adding the complexity of bridging an Objective-C project to Swift. If you start writing Swift without team buy-in, you’ll be labeled as a cowboy coder and may soon be on your way to looking for a new job. Also, bridging code is a pain and takes more overhead than you may think. If the project is urgent or has inflexible deadlines, lean towards Objective-C. Otherwise, consider starting new code in Swift while taking into account the talking points above.

 

Concluding Note

These are the more common factors developers need to address when deciding between Objective-C and Swift for new and existing app projects. Your project may include additional considerations that aren’t normally faced by the bulk of apps. Remember that the most important actions in choosing a programming language are examining the project context and discussing the decision with your team members. Being open to the benefits and drawbacks of both languages and brainstorming options with other developers will help you make the right call when it matters.