Library Evolution in Swift

Swift 5.0 introduced a stable binary interface on Apple platforms. This meant that apps built with the Swift 5.0 compiler can use the Swift runtime and standard library built into the operating system, and that existing apps will remain compatible with new versions of the Swift runtime in future operating system releases.

→ swift.org/blog/library-evolution/

Swift's library evolution support, enabled via BUILD_LIBRARY_FOR_DISTRIBUTION in Xcode or -enable-library-evolution in swiftc, allows framework authors to make additive API changes while maintaining binary compatibility, ensuring clients don't need recompilation.

Resilient changes include adding members to non-frozen types, new protocol requirements with defaults, and implementation tweaks, while non-resilient ones like removing public declarations or altering interfaces break compatibility.

Attributes like @inlinable expose function bodies for optimisation across modules, and @frozen fixes layouts for structs/enums to boost performance at the cost of future flexibility. This feature evolved incrementally since Swift 3, stabilising with Swift 5.1's @frozen introduction for general use.