March 3, 2019

ELI5 ABI Stability

I just listened to this great episode of the Swift by Sundell podcast where Ted Kremenek, manager of the Languages and Runtimes team at Apple, discusses ABI stability in Swift 5 at length. I had a vague notion of what ABI stability meant, but after listening and doing a bit of reading, I definitely feel like I have a better understanding of the details and what it means for Swift's evolution. In this blog post, I'm going to try to give a relatively short, sweet ELI5 explanation about what ABI stability is in the context of the Swift ecosystem, and why you as an app developer, might care.

If you're curious about digging deeper, definitely read some of the official documentation, check out that podcast episode, and/or read some of the many other blog posts on this subject, as they explain the nitty gritty really well.

So, an ABI is a spec for how two binaries interact with each other at runtime. A more common and similar term is API, a higher-level idea which specifies how software communicates at the source code level.

What does an ABI actually do and how is it used? Say you have SomeCoolFramework, compiled with one Swift version, and YourAwesomeApp, compiled with some other version of Swift. In order for YourAwesomeApp to call code from SomeCoolFramework, some low level conventions need to be established. This set of low-level conventions is what you call the ABI.

When you say the ABI is stable, what you are saying is that all of those low level rules have been set in stone. In the case of Swift 5, they've been set in stone strictly for Apple OSes (An ABI is a per platform thing, since it defines hardware-dependent concerns). ABI stability makes it possible for code in Swift binaries, no matter by what version of Swift they were compiled by, to be callable from any other Swift binary. Currently, Swift is not ABI stable, which means that every app must bundle its version of the Swift runtime in order for it to run on future versions of iOS. In a world where the ABI is stable, the OS could provide the Swift runtime to the app.

Okay. How does Swift being ABI stable affect your life as an app developer?

There are a few ways, but one that I think is really exciting is related to Swift's 3rd party library situation. Currently, most of us are used to relying on Cocoapods/Carthage to get dependencies into our projects. See all that code in your Pods/ directory that you have to compile? ABI stability is one step in the direction of a world where 3rd party library developers could ship a pre-compiled framework - which will be great for reducing compile time and will enable developers of closed source SDKs (Crashlytics, Twilio, etc) to rewrite all their Obj-C code to Swift and distribute pre-compiled frameworks.

The other step would be module format stability. Whereas ABI stability is concerned with how compiled Swift code is interpreted and used at runtime, module format stability is about standardizing how the compiler represents Swift code internally to perform tasks like type-checking and code generation. To put it in more concrete terms - we Swift developers have the luxury of not having to write .h files, or header files - it's generated automatically by the compiler. Module format stability is, basically, about standardizing how the compiler synthesizes the interfaces to your Swift code.

So, there you have it. I hope that if you knew nothing about ABI stability, you learned something new. Here's some recommended reading if you want to learn more: