Objective C vs Swift: Which Is The Better Language For iOS Developers?

In a Stack Overflow 2016 survey, Apple’s Swift programming language came in second in the list of ‘most loved programming languages’ (behind Rust). Objective-C – for so long the go-to language for iOS app developers – was nowhere on the list, and in fact, it was mentioned among the ‘most dreaded languages’ this year. The balance of power from Objective-C to Swift is further made evident by results from the TIOBE Index. Swift had lied below Objective-C (15th and 14th places respectively) in November 2015, but had overtaken Obj-C by the first quarter of 2016. According to predictions by mobile app entrepreneurs, Swift should rank among the top coding languages by the end of the year, while Objective-C might just drop out of the top-20 list. Over here, we have done a comprehensive Objective C vs Swift comparison, and tried to find the reasons for the burgeoning popularity of the latter:

1. Volume of coding required – Swift wins hands down on this count. Not only is the amount of coding required less in Swift, but the entire code is a lot simpler as well. Instead of using multiple strings for passing repetitive information (as needed in Objective-C), app developers can easily use the ‘+’ string operator for combining both strings and characters. Since string interpolation is supported in Swift, coders do not have to memorize the used string tokens either. In Obj.-C, any mistake with a string token can cause an app to crash. The inline support for data manipulation is also an advantage of Swift.
2. Dynamic vs Static libraries – Prior to the arrival of Swift and iOS 8, Apple had never provided support for dynamic libraries on the iOS platform. Objective-C developers had to work with static libraries, which were updated only at the time of platform update releases. Swift has changed the game here, and those who make apps can now use blocks of dynamic code in their applications. That way, apps created with a certain version of Swift can be linked with future updates of the language. Obj-C lacks this dynamism.
3. Syntax simplicity and stability – Let’s admit something at the very outset – Objective-C is not a particularly easy language to learn for newbies. The syntax is elaborate, and the same thing can be written in Swift in a shorter, crisper way. However, it also has to be kept in mind that Obj-C, by virtue of being an established language, has a stable syntax, while that of Swift is still evolving. There have also been reports about the frequent crashes of the Swift 2.1 compiler. Swift 3.0 Preview 2 is already out, and the upgrade should sort out the syntax stability issue.

Note: C and Objective-C codes can be seamlessly used in the Swift environment. The reverse, however, is not possible. This an important point in favour of the ‘older’ language.

4. Level of interactivity – The arrival of Swift Playgrounds is one of the biggest reasons behind its rapidly rising popularity among iPhone app developers worldwide. With Playgrounds, coders can test their programs dynamically and on-the-go, instead of having to compile the entire app code (which can often be messy). Swift allows developers to interact with their codes in a much more effective manner than Objective-C ever did. For custom views of codes as well, the Swift Playgrounds are really useful.
5. Swift is ‘swifter’ – Experts from the domain of mobile app development confirm that Swift is comparable to C++ for Mandelbrot as well as FFT algorithms. The code performance of Swift witnessed a big jump since the release of Swift 1.2 and Xcode 6.3. The main reason for the better speeds of Swift is the absence of the general legacy C conventions (which bog down the Obj-C language somewhat). Apple has clearly made an effort to improve app logic with Swift, and the results are for all to see. The API legacy in Objective-C makes it a significantly slower language.
6. Platform portability – Swift is a much more useful coding language for cross-platform app developers than Objective-C. It went open source in December 2015, and has since started to be used on the Linux platform. Reports of Swift is becoming available to Android app developers are also doing the rounds (a ‘Port to Android’ option is already present in the Swift repository master branch). Although the prime focus of Swift is, obviously, iOS, watchOS, tvOS and mac OS X, it is not an Apple-only locked language like Objective-C.
7. Readability – We have already mentioned that coding syntax in Swift is a lot less complex that what it is in Objective-C. Let’s examine this in a little more detail here. For starters, iOS developers do not have to use brackets/parenthesis within if-else statements, or be wary of missing semicolons at the end of each line. The comma-separated parameters used to call methods and functions in Swift is also more convenient than maze of brackets that developers have to deal with while calling methods in Obj-C. In Swift, new keywords do not have to be declared with a preceding ‘@’ either. In all, a Swift program is more easily understandable for non-Apple programmers (Java coders, for instance) than Objective C.
8. Size of app – This is a point where Objective-C has the edge, at least for the time being. iOS applications created with Swift 1.x or 2.x need to have the runtime libraries included in their underlying codes. This, in turn, makes the average Swift app about 15-20 MB larger than a similar Objective C application. However, it is expected that APIs will be stabilized in Swift 3.0, the dependence on runtime libraries will be reduced, and applications created with Swift will no longer be larger than their Obj-C counterparts.
9. That thing about pointers – Pointer handling can be a potentially troublesome task for app makers working with Objective-C, even if it does not seem apparent at first. A ‘no-op’, which is generated when a method with a nil pointer value is called, can throw up a large number of bugs. Identifying and resolving them during the final mobile app testing phase can be a frustrating experience and a waste of time. Swift, on the other hand, uses ‘Optional’ types, which generates compiler error as and when any bug is detected in the nil optional values. These runtime crashes in Swift makes the overall code behaviour much more predictable – a big improvement over the uncertain pointer logic of Objective C.
10. Support from IBM. Support from Apple – Craig Federighi has already hailed Swift as the ‘next major programming language’. While there is no chance of Obj-C being phased out anytime soon, mobile app developers would agree that all the new updates in its frameworks are being made for a single main purpose – to make importing to Swift easier. In collaboration with Apple, IBM has come forward to create Swift sandboxes, conduct app experiments, and develop/deploy via IBM Cloud. All eyes are on the development of the Swift language, and Objective-C is receding to a supporting role in the background.
11. Code maintenance – Swift allows Apple app developers to move away from the cumbersome two-file requirement of Objective-C (yet another problem cropping up from C legacy). The implementation files (.m) and the header files (.h) of Obj-C are included in a single (.swift) file in the newer language. The incremental builds in Swift, allowed by the smart LLVM compiler, can automatically detect dependencies, doing away with the need for performing repetitive tasks and maintaining two code files for each class. In a long app code, this is indeed a big factor.
12. More unified language – That would be, once again, Swift. While both Obj-C and Swift supports Automatic Reference Counting (ARC) for memory management – the support is a lot more holistic for the latter language. For example, while working with any low-level API, or even Core Graphics, iOS developers have to manually manage the memory. This can lead to significant memory leaks (with ARC in Obj.-C being limited to only Cocoa APIs). Swift implements ARC support for both procedural and object-oriented coding, while Objective-C only supports the latter.

Note: Neither Objective-C nor Swift uses any Garbage Collector (like in Java) for cleaning unused memory.

13. Developing for the newer platforms – Let’s round off our Objective C vs Swift debate with a question: which one to use for making iOS applications? Well, for apps that are meant to be compatible with iOS 7 and later versions only, Swift should be the go-to language. As already mentioned, recent updates to Objective-C have mostly been for making it more compatible with Swift. The best reference materials are all available for versions earlier than iOS 7 – and there is a definite chance that such tutorials are no longer completely usable for apps made exclusively for iOS 8, iOS 9 platforms. Yes, Objective-C still has to be learnt by developers – but looking forward, Swift will be the more used language by far.

Swift is easily a less error-prone language for iPhone app makers than Objective-C. The need for manual code synchronization is minimal, lesser lines of code have to be written, and code maintenance is much easier too. Objective-C still has to be learnt by new developers (preferably, before learning Swift) – but Swift has indeed emerged as the more convenient language between the two.