While today Objective-C is primarily known as the language for creating iPhone apps, its development dates back to the 1980s. Soon after being created, it was licensed by Steve Jobs’ company NeXT Computer Inc. to develop NeXTStep frameworks and it later become a groundwork of many iconic Apple products. Based on two other languages, C and Smalltalk, it received its object syntax from Smalltalk, and syntax for non-object-oriented operations from the C language. Therefore, one of the characteristics of the Objective-C language is that it’s very mature and has been tested by several generations of developers.
On the other hand, Swift is a new programming language that was first released by Apple in June 2014. Swift is similar to Objective-C at its core but it also has a number of essential features that Objective-C lacks. Be sure to read our full overview of Swift’s pros and cons in the dedicated article.
Since Swift’s introduction, iOS developers have started passionately arguing about which language is better. Among the general excitement about a new, easier way to build apps, there were sceptics, unsure if the world needed another transformative but forgetful technology. Still, in just three years, Swift became the fastest growing programming language in history. Despite that, Apple continues to support Objective-C as an alternative for old-school developers.
But which of these languages can both make developers’ lives easier and provide a cost-effective solution for a business? From the business perspective, stakeholders usually consider these factors when choosing a language for a project: the cost of development, its duration, and the scope of further innovation. On the other hand, developers take into account simple syntax, a helpful compiler, and code safety. If you’re not opting for a cross-platform approach, making this choice is critical for the success of your project.
Today we compare both languages to make a decisive conclusion: why and when should you use one technology over the other, where does Objective-C succeed, and which benefits give Swift points in the ranking? We’ll consider these factors in our comparison:
- Speed and performance
- Code complexity
- Memory management
- Support of dynamic libraries
- Community recognition
- Long-term outlook
The official Apple website claims that Swift is 2.6 times faster than Objective-C. However some studies indicate that the difference is not as dramatic. Swift and Objective-C are both statistically typed languages that use the same iOS SDK and the high-quality Low Level Virtual Machine compiler. There are differences, however, that impact app performance and we’ll describe them below.
Objective-C uses the runtime code compilation
Objective-C isn’t a fast language. The main reason is that it uses the runtime code compilation, rather than the compile time. This means that when the Objective-C object calls for another object in the code, there is an extra level of indirection involved. Generally, this happens very fast but when the code compilation happens a significant number of times, it becomes measurable. Objective-C is a superset of C and all C functions that you will write in Objective-C will be just as fast. Developers who write the performance-sensitive code often go back to clear C for those inner loops.
Swift was made to be swift
Swift language is a good choice for performance-sensitive code. According to many tests, it shows the performance close to C++ for the FFT algorithms. Swift also outperforms C++ for the Mandelbrot algorithm. Because Swift is still a young language, we can expect even more enhancements soon.
Swift was designed to improve the code safety for iOS products. It was created as a type-safe and memory-safe language. Type safety means that the language itself prevents type errors. The importance of type memory safety is that it helps avoid vulnerabilities associated with dangling or uninitialized pointers. These types of errors are the most common in development and difficult to find and debug. These advantages of the Swift language make it more attractive.
Objective-C approach with null pointers
What’s important to understand about Objective-C’ safety is that it uses null pointers. The pointer is the component of C++ and other C-based languages and it can cause vulnerabilities in security. It’s the method for exposing values that gives developers higher access to the data. The thing with pointers is the way they are handled. In Objective-C when you try to call a method with a nil pointer nothing happens. Then expressions and a line of code become a no-operation (NOP). At first sight, it could seem beneficial because it doesn’t cause a crash, but actually, it may be an extensive source of bugs. A NOP causes unpredictable results that complicate the process of finding and fixing bugs.
Swift was created for clean code
Swift, on the other hand, doesn’t use pointers. If you miss a pointer in the code, perhaps nil value, the app will crash. This approach allows programmers to find and fix bugs quickly. As a result, the code will be cleaner and easier to understand. Such features as generics, optionals, and type interference make an app developed in Swift less inclined to contain unnoticed bugs.
Managing files in Objective-C is a frustrating process because developers must manage two separate files. While Swift requires less maintenance and doesn’t require you to manage two files. The thing is that Swift automatically completes the reliances and performs an incremental build in the file.
Maintaining two separate code files in Objective-C code
Objective-C was created from C and it depends on it when it comes to changes and improvements. Developers have to maintain two separate files of code in Objective-C to improve the efficiency and the developing time of an application. It also requires human effort in synchronizing method names and comments.
Maintenance of the single program code file
Swift, like many modern languages, is easier to maintain. The LLVM compiler and Xmind figure out the requirements and automatically complete the incremental builds. As a result, the Objective C header (.h) file and implementation (.m) file are combined in one single (.swift) program code file.
Objective-C complexity of code structure
Objective-C has a complex code structure since it’s built on the C language. It includes a lot of @ symbols, lines, semicolons, and parentheses conditionals with internal “if” and “else” statements. The @ symbols are used to differentiate keywords and types from C types.
Swift’s syntax resembles English
One of the reasons Swift became so popular is its simple syntax, which makes the language easy to read and write. Contrary to the complicated structure of Objective-C, Swift avoids numerous @ symbols and uses the comma-separated list of parameters within parentheses. Swift also requires writing fewer code strings than Objective-C. It allows you to avoid mistakes and create cleaner code. Swift code resembles natural English speech, just as many modern popular languages.
In order to manage your program successfully, you need code that isn’t too hard to measure. The fewer code lines your app has, the easier it will be to maintain and update.
Complexity of the Objective-C code
If we look closer at the Objective-C code, we will see that text strings are very verbose and require a lot of steps to link two pieces of information. Developers have to use special string tokens such as %s, %d, %@, and provide a list of variables separated by comma to replace each token. With Objective-C, messing up the order or using the wrong string token causes an app to crash.
Swift requires less code
Swift requires much less code for repetitive statements and string handling. This is due to Swift’s features such as adding two strings together using the “+” operator. Swift uses string interpolation that excludes the need to memorize tokens, so developers can insert variables directly in line to the strings such as a button line or a label. This type of interpolation of the strings avoids a common cause of crashes that take place in Objective-C.
Objective-C language supports the Automatic Reference Counting (ARC) inside of the object-oriented code itself. The issue is that it cannot access C code and other APIs as Core Graphics. On the contrary, Swift is more consolidated, and its ARC is complete for procedural and object-oriented paths. Due to this fact, huge leaks of memory with the Swift language are impossible.
Objective-C memory management within the Cocoa API
Objective-C uses the ARC supported within the Cocoa API. ARC is a feature for both Objective-C and Swift languages that manages memory with no programmer effort. The problem is that the code isn’t available for procedural C and some other APIs like Core Graphics. This impacts memory management and causes extensive memory leaks.
Swift supports ARC not only for the Cocoa Touch API’s
The Swift language also uses ARC. The difference is that Swift supports the ARC for all APIs that allow a streamlined way for memory management similar to Cocoa Touch. The issues with Objective-C are solved by making ARC complete with the object-oriented code paths. It saves developers’ time and helps them be less about memory management.
Dynamic libraries support
Dynamic libraries are the executable parts of code that can be linked to an app. The difference between dynamic libraries and static libraries is that dynamic libraries can be linked to any program during run-time. The shared code is loaded once and can be used by a large number of programs. This code can be updated, changed or recompiled without recompiling the application that uses this library. Dynamic libraries are automatically included in the AppStore’s download package. Static libraries are linked at the last step of the compilation process after the program is placed in memory. As a result, the executable file must be recompiled in case any changes were applied to external files. Static libraries are also updated along with other updates like a new OS version. Dynamic libraries can update pieces of code directly in an app.
Objective-C uses static libraries
Objective-C doesn’t support dynamic libraries and this is a major disadvantage. The thing is that they are larger in size because external programs are built in the executable files. Dynamic libraries are smaller because only one copy of dynamic library is being stored in memory. So, if you choose to stay with Objective-C, you should recognize that you will ignore the dynamic libraries support provided by the Swift language.
Swift supports dynamic libraries
Dynamic libraries supported by Swift are loaded directly into an app’s memory and optimize the app’s performance. Direct connection with the app allows them to be updated independently from the OS. It helps keep your solution current, reduces the app size, and speeds up the load time of new content.
For a long time Objective-C was the first and only language for iOS development. After Swift entered the market, Objective-C took second place in the Apple world. Today the company actively educates future Swift users and rolls out features that make it the leading language for Apple.
Objective-C is a mature language
Many developers don’t want to switch from Objective-C because they’ve already invested a lot of time learning it and developing apps in it. Apple hasn’t yet provided the presumed date for when they plan to drop support for Objective-C, but we can assume that they will never do this.
Swift is constantly supported by Apple
Swift is a young language that is growing very fast. It has a vibrant strong community that actively contributes to its formation. At this stage of development, Swift isn’t restricted to the Apple ecosystem only. It’s started running in the Linux environment too. All signs point to Swift becoming an immensely popular programming language.
Though often overlooked, the community — recognition factor can be vital to the success of a technology. The more people using a product, the faster it will be improved, making it better and more accessible to others. Open source languages often have quickly growing communities, which is Swift’s case exactly.
Objective-C fans are staying loyal
Many developers are still using Objective-C for many reasons. The most common one would be that lots of them are experts in the language. In this case, the existing benefits of switching to Swift may not be enough to overcome the costs of learning the new language. Another factor is that Swift isn’t fully formed at this moment and developers are waiting for Apple to start using it on a larger scale. According to the StackOverflow 2018 Survey of the most popular technologies, the difference in adoption of these two languages isn’t too significant. So, engineers are not yet eager to say goodbye to Objective-C.
Swift is open source with a growing community
Since Swift is open source, it gained noticeable community support, which allows Apple to fix bugs in a timely fashion. Apple can gather the feedback and implement the improvements based on it. On the other hand, open source technologies benefit companies who try to save money and they are easier to experiment with without committing.
Making the choice: use cases for both languages
When choosing a programming language, you should first and foremost consider you team’s experience and the project’s specifications. For example, if you already have developers skilled in Objective-C, it’s a bad practice have to them migrate to Swift. There are several instances in which you want to stick to the good, old Objective-C and here they are.
When maintaining an existing project. When your app is already written in Objective-C and you need to update it, better use Objective-C. Technically you can code in both languages for the same project since Objective-C and Swift are interoperable. However, maintaining an app developed in two languages is complicated — you need developers proficient in both languages and they constantly have to switch between languages.
When using C or C++ framework. As we described above, Objective-C is the superset of C and if the project requires the C or C++ framework, using this language is the logical thing to do.
When your app needs to support old iOS versions. Swift supports only new iOS versions from iOS 7 and macOS 10.9 and higher. In case your app has to support the older versions, you have no choice but to use Objective-C.
When you’re short on time. Swift is easy to learn, but like any skill it takes time and effort to master. If you can’t wait for your team to learn a new language, continue using Objective-C.
When you have a large project. Swift is a rapidly developing but young language. One of its biggest cons is the lack of backward compatibility. Meaning that when Swift updates you have to completely rewrite your app for a new version. When you create a small app, rewriting is much easier. But in the case of big projects, you wouldn’t want to update your whole program with each version release.
If you log into any Q&A website such as Quora and ask community members what you should use — Swift or Objective-C — you will most likely hear a choir of voices chanting “Swift!”. Apple created the language as an improvement of the old one. So, no surprise, there’re not many Objective-C evangelists left. However, when you make business decisions, you have to ask yourself questions such as:
- What language does your team already know?
- How much time do you have before the project starts?
- How big is your project?
- Do you have the budget to spend on hiring new developers?
- What do you plan to do in the future with this project?
Developers also have their struggles as it takes time to switch to something completely new. If you can learn a new language quickly we advise you to choose Swift. Apple provides a great opportunity to learn and explore coding in Swift with Swift Playgrounds. And the community is out there sharing and improving the software documentation while making Swift a new programming standard.
What is your experience with both languages? Do you hold the common vision that Objective-C isn’t in Apple’s future? Share your thoughts in the comments below.
Originally published on AltexSoft’s blog “Swift vs Objective-C: Out with the Old, In with the New”