Swift.org blog: Evolving Swift On Apple Platforms After ABI Stability

There is new Swift.org blog post now up written by @Joe_Groff titled "Evolving Swift On Apple Platforms After ABI Stability". The post provides more information on how ABI stability will impact language evolution, particularly on Apple Platforms.


If the same mechanism were used to allow a newer Swift runtime to be bundled to run alongside the OS Swift runtime, the new runtime would have no access to Swift libraries in the OS or ABI-stable third-party Swift libraries linked against the OS runtime.

For development purposes, it still seems like having this mechanism available would be useful, even if it limits the libraries that can be interfaced with. If a Swift app’s only dependencies are C and Objective-C APIs, is there any reason why having a separate in-process Swift library using a separate ABI would cause issues?

It might be possible, but it'd give a worse experience than what you get now with pre-stable binaries, since the "Swift overlays" that are currently embedded with Swift apps to provide the Swift interface on top of ObjC frameworks are going to be absorbed into their associated frameworks going forward. The existing overlay projects may not be compatible with future versions of those frameworks either if they decide to integrate Swift support using the OS runtime. Therefore, a bundled future Swift runtime might not even get the Swift customizations to Foundation, AppKit, UIKit, and other ObjC frameworks that older pre-stable Swifts had available. Such a Swift runtime might be useful for local testing or server-style deployment, but I don't think it'd give a first-class Apple client developer experience.

How is this going to affect Swift on Linux?

1 Like

This clears up a lot of the questions that were being asked over on the other thread.

I think this is a more jarring change for developers to accept now because we have been so used to having the flexibility since Swift's inception of picking and choosing language versions (within reason). It's been a pleasure to use new language features on older OS versions and I think thats how a lot of us wish other frameworks like UIKit works, but alas, thats not the case moving forward.

I just hope that by the time WWDC comes around there are some interesting things that do take advantage of this stability to ease the selling point moving forwards.


The Core Team isn't declaring ABI stability on Linux yet. Finalizing the ABI on Linux is less valuable in the server domain (one of the most active use cases for Swift on Linux) than the (say) iOS app domain since service executables are routinely built from source for deployment in that domain anyway. We also have new platform ports coming up — such as Swift on Windows — that are based on the Swift on Linux port and we want more of that platform bringup work to happen first — with more of the details of the ABI fully audited for those platforms — before finalizing them.


Thanks for the information. Does this have any impact on Linux workflows? I.e. if I am using the Swift Package Manager to build command line applications on Linux and Mac, is there anything I will have to change about my workflow to make it work on each platform?

I guess what I'm understanding is that this change will mostly affect the binary size on Apple platforms, but that the process will not change on Linux at this point. Is that correct?