Software development

A Swift Outlook

Functional Programming, iOS, programming


As we all probably noticed, Apple introduced a new programming language, Swift, at this year's Worldwide Developers Conference (WWDC). It is intended to replace Objective-C, the language that iOS and OS X applications have been written in for as long as these platforms have existed.

New winds are blowing from Cupertino — here are some thoughts three of our developers have on the topic:

Oleg Grenrus

Oleg Grenrus

When Apple introduced Swift in the WWDC keynote, my twitter feed was instantly flooded with #swiftlang tweets:

Guess which language I'd like to work in! [Editor's note: Oleg is in the kissing tree with Haskell.] Yet, that's not always possible, and in my humble opinion Swift will definitely make programming for Apple platforms much more pleasant.

The Optional type is an awesome thing. No more NULL pointer exceptions, though it was more of a problem in Java than in Objective-C. You could make that yourself in Swift (and a former futuricean did for Ruby,) but it's nice that we have some syntactic sugar for this common pattern.

The abstract data types and generics are the most welcome new features: finally we can have typed containers. ADTs are fine, but yet it feels that generics are just glued on top of everything else. As a person who's been exposed to Haskell you immediately try weird things, and when they don't work, you're really disappointed. Hopefully the situation will improve. After all, it did with TypeScript!

Just to show a few examples of what we'd like to do, but can't: you try to combine protocols and extensions with generics:

protocol Functor<A> {
    func fmap<B>(f : A -> B) -> Functor<B>

extension Optional<A> {
    func orElse(def : A) -> A {
        switch self {
        case let .Some(x): return x
        case let .None:    return def

But you have to do:

protocol Container {
    typealias A
    func map<B>(f : A -> B) -> Container // you cannot parametrise protocols

extension Optional {
    // T is implicit, pulled from definition of Optional
    func orElse(def : T) -> T {
        switch self {
        case let .Some(x):
            return x
        case let .None:
            return def

The swiftz library project requires the very same feature to implement higher abstractions. One can argue whether everybody need functors or monads, but at least making such abstractions push the language (and compiler) to the limit.

We hadn't yet had much time to play with Swift — thought someone else already ported FlappyBirds — but the initial feeling is that Swift is definitely nicer than Objective-C. Hopefully it will help us make more awesome apps in even less time than before.

Boris Tschirschwitz

Boris Tschirschwitz

When Apple introduced the Swift programming language at WWDC on June 2nd, it wasn’t the culmination of a four year development effort. This was a MVP release four years in the making.

In parallel to the development of the new language, new features like closures and properties were grafted onto Objective-C and it shows. Blocks can make Objective C programs semantically much more elegant, but syntactically they make code ugly. And for a programmer ugly means hard to read and hard to understand.

For now I see Swift mostly as syntactic relief. I will finally enjoy the flow of my code again.

Swift offers the core set of features expected from a strongly typed modern wrapper around Objective-C. It will be interesting to see how the APIs change to make use of Swift’s features.

Just like C++ has already seen several transformations from Cfront to C++11, Swift will change, too.The less important backwards compatibility becomes the more it can change, “tick, tock, tick, tock” Intel might call it.

Of course, I didn't get all I wanted, so keeping in mind that the language will develop I'd like to mention the following problems:

Most importantly, the total lack of access control is a big step back even from Objective C. Apple has over the years added several features like private class extensions, to give us some access control, but now in Swift these are all gone again. Yes, the Swift team already stated that access control is high on their feature list, but they already spent four years of development time.

With Swift we finally get encapsulated modules, but the language has only an "import" statement to access a module's contents, no corresponding exporting statement. In fact, grouping objects into modules happens completely above the language level, on the compilation target level, so it's impossible to know on the language level, what module an object belongs to. And just like the missing access control for classes, it's all or nothing.

Both of these problems should have been addressed during the first four years of development, as their lack means missing encapsulation and thus less structure in our code.

I would have wished for more language features related to concurrency, maybe atomics, but this can probably more easily be added later.

Also, with a new language Apple had the chance to finally make documentation part of the code. This would have been especially useful in conjunction with the new REPL. Fortunately, this can also be added later.

This brings me to my last complaint: the Swift book. It is a run of the mill "Programming X" book, just rattling down the features with trivial examples. I want to know why the Swift team chose a feature, and why it was implemented in the current way. I also want to know what they are planning for the future.

Almost as important as the new language is the new development environment with its REPL. Finally we can break the write-compile-run cycle and write live code.

I certainly can’t wait to start developing in Swift, and a program written in Swift runs on iOS 7 today. We will be more productive in Swift starting today and that is exactly because Apple designed Swift 1.0 as developer relief.

Let's hope they have a good road map for the future of the language.

I am very proud of the depth of knowledge and the excitement displayed by my colleagues about this new language since it was introduced. Apple encouraged all developers to file bug reports with improvements to Swift, and we already have a bunch of these.

This passion about our craft might sometimes get lost in day-to-day coding, but at times like this everybody wins: We can try exciting new stuff and our customers profit from our eagerness to be experts on day one.

Ali Rantakari

Ali Rantakari

Swift may seem underwhelming for some — that it's not a big enough leap forward from Objective-C. This is understandable, given all the great features that are available in other programming languages, but you have to remember that:

  • Swift uses the same runtime as Objective-C
  • Swift uses all the same system framework APIs as Objective-C (and is thus subject to most of the same “platform idioms”)
  • Swift is ABI-compatible with Objective-C (essentially, the languages can talk to each other, so you can mix and match as you please.)

This pragmatic design makes the language transition as painless as possible: you don't have to learn new APIs, or completely rewrite your existing projects. Instead, you can keep working with Objective-C until you're ready to take on this new language, and then gradually start incorporating it into your apps.

Even though Swift is a completely new language, there is something familiar there for both experienced Cocoa developers and programmers new to Apple's platforms. For the former, it's familiar because all the APIs and their associated platform idioms are the same, and for the latter it's familiar primarily because it eschews Objective-C's strange square bracket message-send syntax in favor of the more common dot notation.

All valid C code is also valid Objective-C code. This is an asset in and of itself, but prevents the Objective-C language designers from improving it in ways that would break this compatibility. Swift makes a clean break and thus introduces many improvements:

  • Much simpler syntax
  • No concept of pointers
  • No concept of instance variables (property storage is more abstract)
  • Values are never implicitly converted to another type
  • Better switch-case with pattern matching and no fall-through

…et cetera, et cetera.

People often complain about Objective-C's “verbosity,” referring primarily to the Cocoa APIs that like to spell things out with their named parameters. I've never agreed with this criticism: in my experience the verbose APIs more often than not make code more readable. I do, however, find that Objective-C code can be unnecessarily verbose, due in part to its C roots, but also because its type inference leaves something to be desired.

This is an area where Swift has clearly been improved with its local type inference. In addition, while I've never had any real issues with the untyped collections in Objective-C, generics are still a welcome addition.

In a world where individual CPU speeds have plateaued for years concurrency is an important topic, and an important tool in writing safe concurrent code is the exclusive use of immutable values. In Objective-C you can of course do this, but it's a manual job based on conventions where the language and the compiler cannot really help you avoid mistakes.

Swift seems to take one step forward and two steps back with regard to this. It does introduce the let keyword for constants, as well as the mutating and nonmutating keywords for structures and enumerations, but the mutability in the standard collection types is very disappointing: for example, you can change the contents of “immutable” arrays so long as their size doesn't change (which is a very surprising definition of “immutability.”)

There also doesn't seem to be a way for a class to expose a property as read-only in its public interface, while keeping it writeable behind the scenes. This, coupled with the language's complete lack of access controls, could be a recipe for an encapsulation nightmare. (Access controls will likely be added in a future version of the language, though.)

Apple's basic pitch for Swift in the WWDC keynote was “Objective-C without the C.” If you adjust your expectations to this premise, right now it looks like they're off to a good start, but it's also clear that the language still needs work. Apple expects to get bug reports and feature requests for the language from the developer community, and someone has set up a public listing of reports submitted to them, along with a request to file duplicates, so that the language developers can prioritize future improvements.


Swift is likely to be the primary language for writing iOS and Mac apps at some point, but it's not yet clear when that time will arrive. Whenever it is, though, Objective-C will certainly stick around for long past that time, so writing your new apps in it right now will not put a “legacy” stamp on your code.

We believe that when Swift 1.0 arrives this fall, choosing between it and Objective-C for new projects is a 50/50 proposition, depending on what you value:

Choose Swift if:

  • You want to “bet on the future” and ensure that your code will be ready for any (distant) future improvements Apple adds to the platform
  • You are willing to wrestle with and work around the initial problems and deficiencies in the new language — this means investing more time and money in initial development, and in refactoring the code later when Swift matures and new idioms and practices become possible and commonly accepted.

If, on the other hand, you want to wait until Swift has matured, choose Objective-C. Swift can be adopted later in a gradual fashion, for example writing only new features in it.