Swift's Approach to SPI

Most, if not all, Swift developers are familiar with Swift’s access control system. It enable us to hide the implementation details of our code and design a clean interface (the so-called API) through which the code can be accessed. While this system is pretty powerful, we unfortunately hit its limits if we want to custom tailor our API for different use cases — such as broadening the number of exposed interfaces for internal products while keeping a more refined public API for third-party consumers. Luckily, there’s a solution — the experimental @_spi attribute — which we’ll explore in a bit more detail in this post.

System Programming Interface

System Programming Interface (SPI) is a somewhat uncommon software engineering term, and it refers to a kind of API that’s exposed to just a limited set of consumers and then hidden for others. An example would be Apple’s system frameworks, which have a well-defined stable public API, but also expose a lot of additional functionality that’s intended solely for other Apple frameworks and applications.

Apple is, however, not the only company that has this need. At PSPDFKit, we also distribute a set of binary iOS frameworks. They include a model-layer framework with PDF APIs, a UI framework, and various optional add-on frameworks. They all have public APIs intended for our customers, but in addition, require internal hooks to facilitate better integration and reuse of helpers. On top of those frameworks, we also built an end-user application — PDF Viewer — in which we use both our private helpers and experimental functionality we’re not ready to expose to our customers just yet.

The @_spi Attribute

In Objective-C, an SPI would be defined by creating a private umbrella header. That header would be made available to internal dependencies but not distributed to third parties. This concept could then be made compatible with Swift API consumers with the help of private module maps. There used to be no built-in way to create the same for a pure Swift SPI — until early 2020, when the @_spi attribute was first introduced to the language.

Attribute

The @_spi attribute defines a new syntax, which is used to annotate public declarations with a custom name. This makes the marked API only accessible from the same module and by clients that import the module with the same @_spi name.

As an example, in the code below, we’re making helper(), a public function in PSPDFKit.framework, part of the Internal SPI:

@_spi(Internal) public func helper() {}

To use helper() outside of PSPDFKit.framework, we need to import it with the following:

@_spi(Internal) import PSPDFKit

This is done instead of using import PSPDFKit.

Module Interface

To make the above example work, PSPDFKit.framework needs to generate a secondary Swift interface (.private.swiftinterface) in addition to the usual .swiftinterface. This is done by adding the -emit-private-module-interface-path compiler option. This file can be included for internal dependencies but removed when distributing frameworks to third parties. This is a manual post-processing step, but it’s where the inconveniences end for a pure Swift product.

Objective-C Compatibility

Swift APIs annotated with the @objc attribute are exposed to Objective-C via a generated -Swift.h header. As there’s currently no distinction between the public and private version of the generated header, the SPIs still end up in the generated header. So, another post-processing step is needed to manually remove those declarations.

Risks

Anyone who’s familiar with Apple’s API naming conventions will immediately recognize the underscore prefix as a problem. Underscored APIs in Swift are considered private, which means there are no guarantees about the stability of their syntax and semantics. Ironically, you need to use the Swift language SPI to be able to model your own SPI.

Consulting the Underscored Attributes Reference, which is the main reference point for @_spi, reveals an obvious and clear warning at the top of the documentation:

WARNING: This information is provided primarily for compiler and standard library developers. Usage of these attributes outside of the Swift monorepo is STRONGLY DISCOURAGED.

However, it’s also clear that this API is already being used by both Apple internally and some third parties, like the popular Stripe framework. While we acknowledge that there’s some risk that this API might change in the future, we’ve received some pretty clear hints that this is generally considered safe and is, right now, the best way to design an SPI in Swift.

Testable as a Suboptimal Alternative

Swift does have another language-level feature to adjust API access control: the @testable import attribute. This — in combination with building with the testability build setting enabled (the -enable-testing flag) — raises access levels to public. In a sense, @testable can be (ab)used to define an SPI by always compiling with testability enabled and using @testable imports where an SPI is needed.

This avoids usage of experimental language features, but it comes with a major caveat. Since the code needs to be compiled with testability even for production builds, we’re exposing all internal symbols — not just to our SPI consumers, but to anyone who imports the framework with @testable import. This reduces encapsulation and leaves the code open to more (accidental) misuse.

The Future of @_spi

Due to the niche nature of SPIs, it seems unlikely that @_spi will become a public feature anytime soon. Talking to Swift language engineers, we found out that they think there’s a better way to describe SPIs as a language feature, but they don’t yet know how exactly that would look, and it isn’t something that’s actively being worked on right now.

All that said, we decided that — right now — this is still the best way to solve our problems, and we’ve accepted the slight risk of potentially needing to refactor the functionality in the future. If the worst happens and the feature is completely removed, we can still fall back to @testable.