Swift vs. Objective-C: 10 reasons the future favors Swift


Web Designer Sometimes
Super Moderator
Mar 11, 2017
Best answers
1. Swift is easier to read
Objective-C suffers all the warts you’d expect from a language built on C. To differentiate keywords and types from C types, Objective-C introduced new keywords using the @ symbol. Because Swift isn’t built on C, it can unify all the keywords and remove the numerous @ symbols in front of every Objective-C type or object-related keyword.

Swift drops legacy conventions. Thus, you no longer need semicolons to end lines or parenthesis to surround conditional expressions inside if/else statements. Another large change is that method calls do not nest inside each other resulting in bracket hell -- bye-bye, [[[ ]]]. Method and function calls in Swift use the industry-standard comma-separated list of parameters within parentheses. The result is a cleaner, more expressive language with a simplified syntax and grammar.

Swift code more closely resembles natural English, in addition to other modern popular programming languages. This readability makes it easier for existing programmers from JavaScript, Java, Python, C#, and C++ to adopt Swift into their tool chain -- unlike the ugly duckling that was Objective-C.

2. Swift is easier to maintain
Legacy is what holds Objective-C back -- the language cannot evolve without C evolving. C requires programmers to maintain two code files in order to improve the build time and efficiency of the executable app creation, a requirement that carries over to Objective-C.

compute-bound tasks in December 2014 using the Mandelbrot algorithm.

In February 2015, Primate Labs discovered that the Xcode 6.3 Beta improved Swift’s performance of the GEMM algorithm -- a memory-bound algorithm with sequential access of large arrays -- by a factor of 1.4. The initial FFT implementation -- a memory-bound algorithm with random access of large arrays -- had a 2.6-fold performance improvement.

Further improvements were observed in Swift by applying best practices, resulting in an 8.5-fold boost for FFT algorithm performance (leaving C++ with only a 1.1-time performance gain). The enhancements also enabled Swift to outperform C++ for the Mandelbrot algorithm by a factor of a mere 1.03.

Swift is nearly on par with C++ for both the FFT and Mandelbrot algorithms. According to Primate Labs, the GEMM algorithm performance suggests the Swift compiler cannot vectorize code the C++ compiler can -- an easy performance gain that could be achieved in the next version of Swift.

7. Fewer name collisions with open source projects
One issue that has plagued Objective-C code is its lack of formal support for namespaces, which was C++’s solution to code filename collisions. When this name collision happens in Objective-C, it is a linker error, and the app can’t run. Workarounds exist, but they have potential pitfalls. The common convention is to use a two- or three-letter prefixes to differentiate Objective-C code that is written, say, by Facebook versus your own code.

Swift provides implicit namespaces that allow the same code file to exist across multiple projects without causing a build failure and requiring names like NSString (Next Step -- Steve Jobs’ company after being fired from Apple) or CGPoint (Core Graphics). Ultimately, this feature in Swift keeps programmers more productive and means they don’t have to do the bookkeeping that exists in Objective-C. You can see Swift’s influence with simple names like Array, Dictionary, and String instead of NSArray, NSDictionary, and NSString, which were born out of the lack of namespaces in Objective-C.

With Swift, namespaces are based on the target that a code file belongs to. This means programmers can differentiate classes or values using the namespace identifier. This change in Swift is huge. It greatly facilitates incorporating open source projects, frameworks, and libraries into your code. The namespaces enable different software companies to create the same code filenames without worrying about collisions when integrating open source projects. Now both Facebook and Apple can use an object code file called FlyingCar.swift without any errors or build failures.

8. Swift supports dynamic libraries
The biggest change in Swift that hasn’t received enough attention is the switch from static libraries, which are updated at major point releases (iOS 8, iOS 7, and so on), to dynamic libraries. Dynamic libraries are executable chunks of code that can be linked to an app. This feature allows current Swift apps to link against newer versions of the Swift language as it evolves over time.

The developer submits the app along with the libraries, both of which are digitally signed with the development certificate to ensure integrity (hello, NSA). This means Swift can evolve faster than iOS, which is a requirement for a modern programming language. Changes to the libraries can all be included with the latest update of an app on the App Store, and everything simply works.

Dynamic libraries have never been supported on iOS until the launch of Swift and iOS 8, even though dynamic libraries have been supported on Mac for a very long time. Dynamic libraries are external to the app executable, but are included within the app bundle downloaded from the App Store. It reduces the initial size of an app as it is loaded into memory, since the external code is linked only when used.

The ability to defer loading in a mobile app or an embedded app on Apple Watch will improve the perceived performance to the user. This is one of the distinctions that make the iOS ecosystem feel more responsive. Apple has been focused on loading only assets, resources, and now compiled and linked code on the fly. The on-the-fly loading reduces initial wait times until a resource is actually needed to display on the screen.



Mar 16, 2017
Best answers
Wow this is a lot of info! I am glad you posted it, even though I am not vested in the mobile world I know many are and will love to see this!