Swift, Apple’s New Progamming Language. Simplifying and Improving Performance One Line Code at a Time.



From a developer’s perspective, the biggest surprise coming out of WWDC this year was the announcement of Swift, a new programming language for Cocoa and Cocoa Touch. Swift is poised to replace Objective-C, a stalwart in the Apple development world.

Though Objective-C has been used for the Mac OS since the mid-90s, it was catapulted into the spotlight by the advent of the iOS App Store in 2008 and the ensuing developer “gold rush.” Since then, largely due to demands from the community, Apple has worked tirelessly to “modernize” the old language by eliminating the need for redundant code, expanding support for literals and subscripting, and introducing ARC to handle memory management among other things. While this has helped to make development with Objective-C more efficient, the reality is that it still lags behind the “modern” paradigm it was chasing. It was inevitable that in order to keep up, Apple would have to institute a wholesale change, and that’s where Swift comes in.

Swift is designed to be concise, efficient, and built for “lightning-fast” performance (according to Apple). Here’s a breakdown of some of its core features:

Modern Syntax


The first feature Apple showed off, even prior to bringing Chris Lattner, the language’s creator on stage, was how concise its syntax is. This is an obvious departure from Objective-C, which is viewed as heavy-handed and verbose. As someone who obsesses over the legibility of code, this was incredibly important to me (after all, one of the first lines of Genuine’s code-formatting guideline is, “Always consider readability when writing code, even when factoring in performance.”) The example given during the WWDC keynote highlights a routine exercise that’s part of the oft-used delegate design pattern in Objective-C:

if ([myDelegate respondsToSelector:@selector(scrollViewDidScroll:)]) {

[myDelegate scrollViewDidScroll:myScrollView];


While it is lengthy, its intention is clear. In Swift, this becomes:


It’s certainly shorter, but is it better? I would argue so. Like any language, you have to learn how to read it, and once you do, it translates to essentially the same thing as the snippet in Objective-C. The above example reads, “If myDelegate exists and has a method named scrollViewDidScroll, call it with the parameter myScrollView.” Sounds pretty similar, right? Another benefit to this is that due to features of the language, it’s actually safer and more specific than its Objective-C counterpart. Being compact yet straightforward to read, and accomplishing more at the same time is ultimate goal of code legibility, and Swift definitely accomplishes this.

Safe Coding 

The ability to check for errors and warning in real-time has been a staple of modern IDEs today. Objective-C is no exception to this, with the need to hit the compile button just to identify typos virtually eliminated. But compilation errors are only as good as the language allows them to be, and one of many goals of Swift was to improve upon this. This includes the addition of many new features:

  • Support for tuples and generics, expanded support for structs and enums, and the unification of closures and function pointers, which allow for complex functionality to be more formally and succinctly defined.
  • Strong, statically typed, inferred variables, including built in support for typed collections such as arrays and dictionaries.
  • Immutable variables (constants) and mutable variables, defined using let and var respectively, available within any scope (and without requiring subclassing, like Objective-C).
  • Required initialization of all variables unless explicitly defined as optional, eliminating the need for the ambiguity of evaluating or messaging a nil pointer.
  • Automatic overflow checking for numbers and arrays.
  • Required explicit conditionals, meaning pointers, integers, etc. may no longer be used as conditionals without an actual comparison.
  • No implicit casting for math operations unless operators are overloaded to do so.

These features and many others all add up to creation of sound code before you compile, eliminating potential run-time or logic errors that could have been missed in Objective-C. Overall, this will yield more stable, reliable code, which is never a bad thing. 


As a developer, performance is always an important factor. On mobile devices, this is amplified by compact hardware and limited battery life, making performance a key consideration when evaluating code.

So, is Swift the magic bullet that will fix all your performance problems? The answer, is of course no. The responsibility still falls largely on the shoulders of the developer. In addition, until Apple rewrites all of its system frameworks with Swift, most everyday use cases will remain the same. Swift does, however, help to stack the deck.

Unlike Objective-C, which has transitioned to the LLVM infrastructure over the years, Swift was designed from the ground up to take advantage of the modern features of LLVM. It also doesn’t hurt that one of LLVM’s creators happens to be the aforementioned Chris Lattner, the creator of Swift. In fact, he created Swift specifically because LLVM’s capabilities were outpacing the modernization of Objective-C.

As a result, Apple claims that Swift can be nearly twice as fast as Objective-C for computationally heavy, processor intensive algorithms. While it’s still largely untested by the community, with Apple committed to both LLVM and Swift, it will likely only improve.


Given Apple’s progressive history when it comes to major paradigm shifts in technology, it’s a safe bet that Swift is here to stay. Just look at the advent of Mac OS X or Apple’s switch to Intel processors. Leveraging some the best parts of Objective-C, and drawing on the better qualities of many other languages (I see elements of virtually every programming language I’ve worked with), Swift appears to be the natural successor to Objective-C and future of iOS and Mac OS development. Genuine’s developers are looking forward to seeing what we can accomplish with it.

One thought on “Swift, Apple’s New Progamming Language. Simplifying and Improving Performance One Line Code at a Time.

  1. Michael D.

    Lack of implicit casting is not feature its a huge determent to being a “swift” programer. From C to Java, developers have managed to get by with the specter of a truncated long looming over them for decades. I used to maintain a C grammar and the truth is implicit casting is a huge complicated pain to implement, but forgoing the headache is NOT a feature. I’ll forgive the unnecessary syntactic clutter of colons and arrows, but using “as” to cast three of six variables turns a tight geometry calculation into an incomprehensible mess. Forcing a developer to re-stack allocate every other variable is almost as bad but still necessitates a lot of head scratching and causes enough refactoring that incredible subtle bugs can appear in functions that have been around for years. Instead of “That close to zero variable is a zero.. I must have a casting problem.” We now get – “Something in that three thousand line code base was translated wrong because when I have two bezier curves that are nearly parallel they think there interacting.”
    Don’t get me wrong Swift is a monumental improvement of Objective-C. But in the interest of “eliminating common programming errors” they have introduced a host of more subtle ones. For instance pass by value arrays are fine until you have a two million item array that you are trying to move between class dozens or hundreds of times a second and suddenly your performance craters or you get a stack overflow exception. This in my view at least is a substantially more difficult to understand and avoid error then a null pointer exception.
    All in all I agree with you that Swift is a step in the right direction but is obviously incomplete, I hope that the list of features that eliminate common programming errors shrinks a good deal and quickly.


Have Something to Say?

Your email address will not be published. Required fields are marked *

four × 5 =

Recent Posts

Recent Comments