Sergey Nivens - Fotolia
Developers who build iOS applications have access to a wealth of tools, frameworks and libraries. However, when it comes to languages, many still find themselves stuck with choosing between two languages: Objective-C and Swift. While both languages boast strong communities of support, the changing development landscape has significantly shaped and demonstrated the most important ways they differ.
So, which to choose: the proven and robust -- but possibly outdated -- Objective C, or the newer Swift? In this article, we'll look at the history and key features of each language, and review some considerations to take before choosing one over the other.
Objective-C was introduced in the 1980s, and introduced tools that eventually became the Cocoa platform for iOS, macOS, watchOS and tvOS development. It's based on an object-oriented programming approach, which revolves around dividing code into classes and methods. As the natural language of the iOS framework, Objective-C is a superset of C, but adds additional features like a bracket-style messaging syntax.
One of the major benefits of Objective-C is the easy access to C and C++ functions and libraries. For example, making API calls with Objective-C may feel more intuitive to C and C++ veterans. In addition, the relationship between the Cocoa framework and Objective-C code provides a strong advantage when it comes to building complex applications.
However, that scenario continues to change with every new Swift release. Finally, the Xcode IDE was built with Objective-C and it offers a potentially more stable environment for building iOS and OS X applications than using Swift, particularly when working with advanced codebases.
Here are some of Objective-C's most praised characteristics:
Reusability through objects
Messaging is a key attribute of Objective-C, not to mention a pillar of object-oriented programming. By passing messages as function-invoking objects, developers can organize code into reusable blocks of code that are easy to replicate for other applications. Furthermore, developers can tie those function calls to specific objects at runtime rather that at compile time, adding a little flexibility to Objective-C implementations in terms of reusing those functions.
Runtime variable assignment
Objective-C is dynamically typed, which means variables are assigned to objects at runtime. This adds a great deal of flexibility when it comes to assigning particular variables to multiple types of objects. However, it does come at a slight performance hit, since it forces the application to check for errors with each new execution rather than delivering clean code from the start. However, this does afford developers the freedom to implement a number of different design patterns, including proxy and observer patterns.
Due to the superclass structure of Objective-C, developers can add methods to classes at runtime without the need to recompile them later. They can then use these classes and structures to define custom data types as blocks of code.
Another key attribute is that Objective-C applications can inspect all defined classes at runtime while allowing for custom classes and new methods. Certain Apple classes and scripting languages capitalize on this to offer helpful capabilities. For instance, AppleScript uses this characteristic to automate repetitive coding tasks, while UndoManager uses it to provide developers an easy rollback mechanism.
Apple released Swift to the open source community in 2014, branding it as a general-purpose compiled language. This release marked a strategic shift away from proprietary languages like Objective-C, and aimed to fulfill the needs of server-side and cross-platform developers. In fact, Swift seems to slowly be closing in on the goal of its creators: to replace Objective-C.
Developers can employ Swift for not just all Apple OS platforms, but also for Windows and Linux. Swift maps closely to the low-level virtual machine (LLVM) compiler framework, and features a very clear, concise syntax, which some say provides better readability compared to Objective-C. To date, Swift compile times have been notably slower than Objective-C. However, subsequent releases yield increasingly faster performance, and developers can simply adjust project settings or code to improve build times.
Here are some of Swift's top features:
Automated memory management
Memory management in Swift is considerably automatic and streamlined. For example, the Automatic Reference Counting (ARC) feature adds scalability by automatically tracking memory usage and eliminating manual memory management tasks. The ARC is implemented at compile time, and Swift's compiler helps to increase or reduce the number of reference calls as necessary. When data is no longer needed, ARC automatically removes it to free up space.
Dynamic libraries also help reduce Swift's overall memory footprint. In general, Swift relies on the Objective-C runtime library which enables C, C++ Objective-C and Swift code to all run seamlessly within one program. The Cocoa Pods dependency manager provides additional libraries to compensate for the limited number of mature Swift libraries, and also simplifies implementations, defines dependencies and manages updates over time.
API and framework integration
Swift integrates seamlessly with the Cocoa API and Cocoa Touch framework, which are both foundations of iOS development and provide a cavalcade of powerful design tools. Swift developers can also integrate with server-side frameworks like Vapor and Kitura, or machine learning platforms like TensorFlow. Finally, SwiftUI offers a declarative syntax that works well within the Xcode IDE.
Objective-C vs. Swift
In general, developers who use Objective-C appreciate its rich Cocoa types, dynamic runtimes, messaging syntax, and the fact that the language remains generally unchanged even as new frameworks are added. But according to a 2020 survey by Stack Overflow, 76.6% of respondents identified Objective-C as one of the most dreaded languages to adopt.
By comparison, Swift programmers praise its fast compile times, automated memory management and clean code. On top of that, Apple clearly intends to support the language as a core part of Apple OS development, as it continues to create and release increasingly robust APIs designed for Swift. However, developers might still find integration a little problematic when it comes to taking a Swift, standard-library and combining it with the design patterns and class hierarchies embedded within Objective-C.
The main complaint about Swift is that frequent updates can make it difficult to continually keep track of what the best tools for the job are. Some developers also report limited interoperability with third-party IDEs and a lack of support for older versions of iOS. Successive releases also mean developers must frequently wade through piles of online documentation and tutorials, some of which either have or will quickly become out of date and obsolete.
As the historical foundation of iOS development, there's no question that Objective-C provides unparalleled support for rewriting existing legacy applications and provides much-needed comfort to developers who prefer a proven, dependable object-oriented approach. While it's true that Swift essentially aims to remedy every shortcoming of Objective-C and pioneer a new standard of development, there's a good chance that adopting Swift for a traditionally C-based team will require significant investments of capital, development time and resources.
For iOS developers in general, the safest path is to pursue a degree of proficiency in both languages. But when choosing the best one for your project, ask yourself these important questions:
- Are we looking to build new apps, or mainly update existing ones?
- Does the language support our most essential capabilities, tools and integrations?
- What languages are our developers already comfortable with?
- Is our team motivated to learn a newer language like Swift?
- Do we have the resources to onboard new developers with Swift experience?
- Are we trying to pursue new architecture or design styles?
- How business-critical is the application in question, and what are the reliability requirements?
- Is it possible to have developers work on Swift projects alongside Objective-C projects?