Programming languages have long considered the Application Binary Interface (ABI) to be merely an artifact of implementation that is not considered part of language design. As such, most languages opt not to define a stable ABI when compiling to native code (e.g., Rust, Go) while others avoid the problem entirely by executing on a virtual machine (e.g., Java and other JVM languages, C# and other CLR languages, Dart). However, many software ecosystems require both long-term ABI stability and the ability to constantly evolve. These systems tend to use C as the stable ABI, but evolving software components with a C ABI requires programmers to manually and proactively introduce extra levels of indirection to account for potential future evolution. Swift is a programming language designed to explicitly account for a stable ABI. Swift espouses a principle of least regret for public interfaces, ensuring that the implementation details of a software module, such as the stored contents of a data type or the implementation of a generic function, do not create a binary-compatibility contract that prevents future evolution. By explicitly modeling the boundaries between software modules that evolve separately, Swift is able introduce appropriate indirection across separately-evolved software modules while optimizing away that indirection within software modules that are always compiled together. In this talk, we’ll describe Swift’s approach to binary-stable evolution and it’s impact on the design and implementation of the language.