Swift ABI Stability and More
This post describes what binary compatibility means in Swift 5 and how it will evolve in future releases of Swift.
[…]
To remove this restriction, the library author needs a feature currently being implemented called module stability. This involves augmenting the opaque [swiftmodule] format with a textual summary of a module, similar to what you see in Xcodeʼs “Generated Interface” view, so that clients can use a module without having to care what compiler it was built with. You can read more about that on the Swift forums.
[…]
Swift already has an implementation of support for library evolution, informally termed “resilience”. It’s an opt-in feature for libraries that need it, and it uses not-yet-finalized annotations to strike a balance between performance and future flexibility, which you can see in the source code for the standard library. The first of these to go through the Swift Evolution Process was
@inlinable, added in Swift 4.2 (SE-0193). Look for more proposals about library evolution support in the future.
Previously: Swift 5 Release Notes for Xcode 10.2 Beta.
Update (2019-02-11): Joe Groff:
However, as a result of this, the Swift runtime is now a component of the user’s target operating system rather than part of the developer’s toolchain. As a consequence, in the future, for a Swift project to adopt new Swift runtime and standard library functionality, it may also have to require new OS versions that include an updated Swift runtime supporting the added features. This tradeoff between adopting new language features and frameworks or maintaining compatibility with older OS versions has always existed for Objective-C and Apple system frameworks, and will now be a factor for Swift as well.
[…]
The language compatibility setting is a purely compile-time feature that is used to control source compatibility. It does not affect ABI. You do not need to migrate Swift 4 code to Swift 5 mode in order to use Swift 5’s stable ABI, and going forward, new language modes can be adopted without imposing a newer OS requirement if language features that require new runtime features are not used.
It will not be possible to update the shared Swift runtime from a copy bundled with an app. But apps can continue to ship newer versions that are self-contained, as this is the only way Swift apps can run prior to macOS 10.14.4 and iOS 12.2.
