What is ABI stability?

Jul 05, 2019ios

The Swift 5 release will provide ABI stability for the Swift Standard Library. ABI stability enables OS vendors to embed a Swift Standard Library and runtime in the OS that is compatible with applications built with Swift 5 or later.

What is ABI Stability

Don’t confuse with API which consists of data types, structures, constants, functions that you can use in your code to access the functionality of that external component. Whereas the ABI defines the structures and methods that your compiled application will use to access the compiled external library only on a lower level.

ABI (Application Binary Interface) is the specification to which independently compiled binary entities must conform to: how to call functions, how their data is represented in memory, where their metadata is and how to access it and how an application should make system calls to the operating system.

ABI Stability means locking down the ABI to the point that future compiler versions can produce binaries conforming to the stable ABI. It enables binary compatibility between applications and libraries compiled with different Swift versions.

Why does Swift support it

Before Swift 5, application built with a Swift dynamic library is going to be embedded to that bundle, in order to support your specific Swift version. This leads to bigger app sizes, and version incompatibility issues.

ABI stability is about mixing versions of Swift at run time. Swift 5 reached an important milestone when supporting stable ABI. Here are some benefits it brings to the maturity of language itself and the ultimate benefit to the Swift ecosystem:

  • Source compatibility: newer compilers can compile code written in an older version of Swift
  • Binary compatibility: an app built with one version of the Swift compiler will be able to talk to a library built with another version
  • Reduced bundle size: no longer have to include the Swift standard library in your Frameworks folder
  • Binary frameworks: enables the distribution of frameworks in a binary form that works across multiple Swift versions (along with module format stability) and be able to create closed source 3rd-party libraries

Components of the Swift ABI

What follows is a breakdown of the different kinds of components in Swift ABI and what needs to be specified.

  • Data Layout: a defined in-memory layout for instances of type
  • Type Metadata: a set of defined APIs for querying the metadata of a type
  • Mangling: any name in source code might not be globally unique, a unique name is produced through a technique called name mangling
  • Calling Convention: functions must know how to call each other
  • Runtime: dynamic casting, reference counting, reflection, etc
  • Standard Library: defines many common types, structures, and operations on these

The future to ensure binary compatibility

The challenges to maintain binary compatibility when you’re shipping frameworks in binary form:

  • Published public functions and types cannot be removed or changed in ways that break binary compatibility.
  • Choosing what code to make inlineable will affect performance and flexibility.
  • Internal functions called by inlineable code become ABI, and are subject to the same binary compatibility concerns as public functions.
  • Non-resilient types cannot change their layout.
  • Protocols cannot add new requirements.