Swift 5.0 will introduce ABI stability and that’s about it

Over the course of the last two or three years, we’ve seen Swift establish dominance over Objective-C in both in-house and customer development projects as well as in iOS programming blogs, WWDC sessions and open source libraries. The language was open-sourced in 2015 and has seen three major version upgrades, each introducing backwards-incompatible language syntax changes. While this has inevitably added to the workload of library maintenance, every change has been for the better, making the update work less of a chore.

Compared to its “predecessor” Objective-C, development in Swift has always been faster. It is much less verbose to write and a lot more expressive, while being type-safe. It’s syntax is pretty and consistent – no more need for a block syntax cheat sheet. In its current form, writing robust code has become notably less error-prone than with Objective-C. With its release scheduled for early 2019 (according to the Swift Language Evolution project), the new version will introduce some of the most important additions to date with ABI (Application Binary Interface) stability as the stand-out feature.

The other scheduled features are mostly small tweaks to the String class and some of the other standard APIs. Interestingly, there is also some under-the-hood groundwork for a new concurrency model happening.

What’s there to improve with concurrency?

asyncFunction1 { [weak self] result1, error in
  // error handling, result processing
  asyncFunction2 { [weak self] result2, error in
    // error handling, result processing
    asyncFunction3 { [weak self] result3, error in
      // error handling, result processing
    }
  }
}

Fig 1. Typical Pyramid of Doom with Swift’s closures as async callbacks

The new concurrency model will try to tackle issues caused by programming structures relying heavily on asynchronous callbacks. Often called the Pyramid of Doom, this mechanism not only makes your code look funny and hard to follow but also exposes you to several easy pitfalls caused by closure capture mechanics, threading/error handling and, ultimately, often leads to memory leaks and race conditions. The new model probably aims to rid developers of shared mutable states via asynchronous control flow and coroutines.

There is quite a bit of speculation about the specifics of the new model in the Swift blogosphere. According to Language Evolution, however, nothing too final will make it to version 5, so we will not go into it in this article. At this point, the important thing is probably to lay a foundation that will not compromise ABI stability later.

Why is ABI stability important?

Just like API (Application Programming Interface) stability, the ABI is a well-defined interface that is required for integrating software entities. If you introduce an incompatibility to your API – say, change the name or the type of a method parameter – your older API clients will break down. The clients of over-the-network APIs, such as gRPC/REST, will no longer be able to communicate properly with the server, and the library users of local APIs will not compile any more. Similarly, if your build environment is not ABI-stable, your software modules built with different compiler/language versions may not (will not) be interoperable. This makes it impossible to distribute binary libraries that would work in other environments.

Currently, all Swift libraries are distributed as source files, e.g. as CocoaPods packages, in order to compile them into the host application. The Swift language itself must also be built into the final application.

Therefore, Swift 5’s ABI stability will provide two major improvements. The first, and most obvious, is that you will be able to build and distribute binary libraries using the Swift language. This is important when building closed-source libraries; you are currently stuck with using Objective-C, a quasi-legacy language by today’s standards and something that I personally don’t see any young iOS programmer wanting to learn or use. The second major improvement is one of convenience: as there is no longer need to incorporate Swift itself into your applications (the OS will provide it), your bundle size will drop significantly. And, as a side effect, ABI stability will mean less drastic changes to the language and its standard APIs, making our beloved Swift a more mature programming environment.

References

Swift Language Evolution project, GitHub
Qvik’s open source Swift libraries, GitHub
Wikipedia: Application Binary Interface

Want to work with Swift? We are always hiring, qvik.wpengine.com/careers.