Swift Programming Language: Evaluating Its Readiness for Real-World Development/

Swift is a programming language developed by Apple for macOS, iOS, watchOS, and tvOS app development. It was introduced in 2014 as a modern alternative to Objective-C, which had been the language of choice for Apple app development for many years. While there are many articles that extol the benefits of Swift, this article will focus on some of the considerations you should make before learning app development with Swift.

Before Swift: Objective-C, C, and C++

Before Swift was introduced, developers were limited to writing apps for Apple devices using Objective-C, C, or C++. This was due to Section 3.3.1 of the iPhone OS 4 SDK Developer Agreement, which stipulated that applications must be originally written in one of these languages. While Objective-C was the language of choice for most developers, it was not without its issues. Many people were already dissatisfied with Objective-C even back in 2010, and as a result, alternative ways to write iPhone apps in other programming languages were already cropping up.

Enter Swift

Fast forward four years to 2014 when Apple introduced developers to its new language, Swift. This new language was designed to be more modern than Objective-C and had some important differences. For example, Swift is not a strict superset of the C language, which means that it is free to make use of syntax constructs that would otherwise not be allowed. Additionally, Swift is statically typed, not dynamically typed, which allows it to take advantage of many of the recent advances in type systems pioneered by languages such as Haskell.

Compatibility with Objective-C

To their credit, the developers behind Swift have done a fantastic job making interaction with existing Objective-C libraries as painless as possible. That is not to say that the process is completely pain free though. Apple has provided a helpful guide explaining how to call Objective-C code from Swift, and vice versa, but there are some important impedance mismatches to be aware of.

Perhaps the most obvious mismatch relates to header files. Objective-C, owing to its C roots, still requires that functions be declared before being called. When calling out to a library, these declarations will be found in the library’s header files. Swift, however, does not use header files. So, if you want to call Swift code from Objective-C, you will first need to create a “bridging header”. While conceptually this may not seem that complex, in practice, it actually can be quite the task.

Another set of complications in interfacing between Swift and Objective-C stems from the inherent differences in their type systems. Swift, taking a cue from other modern languages, has done away with the concept of nil. In its place are Swift’s optional types. For example, a method that opens a file only if it already exists would have a return type of File? (Instead of just File) in Swift. By tracking all the places where types are optional, the Swift compiler can effectively make it impossible to encounter the dreaded “Null Pointer Error”. That is, of course, unless you’re calling Objective-C. Since Objective-C makes no such guarantees about not returning nil, Swift has a special category of types called Implicitly Unwrapped Optionals that are used when calling Objective-C code. These types can be treated as optionals in the Swift language, along with all the accompanying overhead required for existence checking. Alternatively, they can be used the same as any non-optional type, but if Objective-C does return a nil you will end up with a runtime error, so you lose some of Swift’s compile-time safety guarantees.

Faster than Objective-C?

One of the benefits of Swift that was especially emphasized when it was introduced was its speed. Objective-C, being essentially an extension to C, was capable of creating much faster, more efficient programs than something like Python or Ruby. However, Objective-C is no rocket ship when it comes to absolute performance, and much of that can be attributed to dynamic typing. With Swift adopting a static type system, one would expect that Swift should be at least as fast, or faster, than Objective-C.

The Compiler

Aside from compilation speed, the Swift compiler has started to show cracks under the stress as it has been unleashed on the masses. There is even an entire GitHub repository dedicated to collecting examples of code that will cause the Swift compiler to crash. Another project on GitHub is collecting speculation and analysis from the community on what changes might be in store for Swift. For example, custom operators can place significant strain on a parser.

Community

The iOS/Objective-C community does not have the best reputation for being friendly and welcoming. That is gradually changing, and open source is increasingly playing a more important role in Objective-C development. Still, at this early stage, it’s hard to tell what the Swift community will look like going forward.

Should You Learn Swift?

Choosing the right tool for the job requires intimate knowledge of all the details of the project in question. At this point in time, Objective-C remains the “safe” choice for iOS development, but Swift is definitely worthy of consideration. The most significant change that Swift brings