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.
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.
Apple and IBM move forward with Swift.
Apple and IBM have joined their efforts and invest in Swift together. After it went open source, IBM began its development actively in several directions. IBM Cloud gives opportunities not only to develop and deploy but also to share Swift resources and use Swift Sandbox for quick experiments.
Objective-C instead was left outside the main game. It is now turning into a subline having few updates which are mainly done for compatibility with Swift. All frameworks are written in Objective-C and are very unlikely to be rebuilt from scratch in the new language. In other words, the latest changes in Objective-C were all aimed at making it easier to be imported into Swift code.
There is no better proof of this point than the words of Apple’s Craig Federighi: “We think Swift is the next major programming language; the one people are going to be programming in for the coming several decades.” Think about it.
Less code, less legacy.
Swift is a more compact language for programming. Less code equals better readability. This fact doesn’t imply code simplicity, of course. Sometimes, it can be very difficult to write, but brings more benefits, being highly reusable. The latter point cannot be applied to Objective-C.
Let’s take a real example. There is a famous app called Lyft. It was rewritten in Swift from scratch. The idea was quite risky because the team started at the early stages of the new language and worked along with the improvements in Swift. What was the bottom line of all that? The app went from 75000 lines of code to 25000. This stunning change did not influence the performance of Lyft, and the customers experienced no difference in its work. The result speaks for itself.
Swift is less error-prone.
Its syntax and language constructions exclude the several types of mistakes potentially possible in Objective-C. This stability means fewer crashes and cases of unexpected behavior. It does not prevent from writing bad code, of course, but a developer is more protected from making unwanted mistakes. All this gives reasons to consider Swift as a safe programming language, which is very important.
Swift is faster.
Its performance approaches the one of C++ which is considered the fastest algorithm calculation arithmetics. Checkout this repository (comparison with Objective-C) and this report (comparison with C++) to see what I mean.
We all see how Apple strives to improve the speed of Swift. They have, actually, been doing it very successfully so far. For example, Swift has beaten C++ in several computation algorithms, such as Mandelbrot algorithm. Objective-C is slower because it contains C API legacy and uses runtime dispatching.
It’s not just for iOS.
Sure, Swift works great on Apple platforms. But you can also use it on Linux, with Apple providing pre-built binaries for Ubuntu. This can be a real boon for developers who want to write code server-side and client-side as it opens up opportunities for sharing functionality.
Some members of the community have taken things even further and have managed to get Swift code working on Android and Windows.
Swift is open-source.
It’s not often you get a chance to shape a new language like Swift from the beginning. Everyday Swift becomes faster, more stable, and more fully-featured, all thanks to the community.
When Apple open sourced Swift they made a separate repository that will be used to house proposals for enhancements and changes to the language, called swift-evolution. Swift-evolution is designed to be the place to go for more substantial language changes.
Swift 3.0 is already being discussed in terms of what features will, and will not, be making it into the release. There is a list of the aims along with a list of some of the things that won’t (yet!) make it into the 3.0 release, such as C++ interoperability and language support for concurrency.
Swift is interactive.
Swift Playgrounds have introduced new opportunities to developers. This tool makes it possible to test code on the spot without compiling big pieces of it or creating the whole app. Playgrounds visualize data and programmers can quickly check and correct everything along with further development. It is especially applicable to custom views and code experiments.
Swift is closer to other platforms.
This point is very important especially when speaking about cooperation of programmers building the same app on different platforms. Apple’s modern programming language is easier to understand for non-iOS developers and minimizes time for additional explanations and clarifications. This, of course, influences the productivity of work positively.
Moreover, Swift can be used as a script language. It is an interesting solution for the iOS community to unify writing of build scripts. At the time being iOS developers are split up in regard to this activity. Some of them write build scripts in Bash, others use Ruby, Python, etc. Swift gives an amazing opportunity to be applied to all iOS programming needs. Do you agree that it is easier to use one (especially your “native”) language only than to work with two simultaneously?
So, what is good about Objective-C?
– Code, written in Objective-C and C, can be used in Swift, but not vice versa. For example, the existing solutions and libraries were all created in Objective-C but are used in Swift without any issues.
– C++ code cannot be used in Swift. It is, however, possible to use Objective-C++.
– Objective-C can be compiled into static libraries and dynamic frameworks, while Swift can be compiled only into dynamic frameworks.
– The syntax of Objective-C is stable while Swift syntax is still improving. Nevertheless, Swift 3.0 promises to bear breaking changes that will not be followed by other great ones. This means that developers will have to convert code from Swift 2.1 to Swift 2.2 and only then to Swift 3.0. Experience shows that sometimes converting runs unsmoothly and it is necessary to rewrite pieces of code. Not the most convenient thing, of course, but we have to understand that Swift is a new programming language and updates are unavoidable.
– Apps written in Swift before ABI stability will be 10-20 Mb bigger in size than the ones built in Objective-C. Everything depends on architecture here. The reason is that all Swift runtime libraries have to be included in an app
– Xcode does not support refactoring of Swift code. It should be done manually. This feature is available only for Objective-C.
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.