I’ll have to concede we have probably missed the boat this time around. I just wanted to make sure I was off the critical path. The flap was due to the “it’s now or never” aspect of the impending ABI freeze in Swift5. I'm sure Doug, if you say I should reuse the existing protocols it is possible but I’m also sure it’s going to be more difficult. (I wrote the rest of this post before seeing your reply...)
Is it worth perhaps taking a step back to double check that the movement to ABI stability is absolutely necessary? I’m not convinced myself.
I have to admit I winced when I heard the phrase “Bake Swift into the operating system” at this years WWDC as I’m under no illusions just how difficult a technical feat this is going to be and it’s far too early in Swift’s lifecycle to be talking of freezing things. Swift has a very large ABI surface due to the prevalence of value types and it’s avoidance of “late binding” so there is plenty of scope for things to go wrong.
That said there are compelling reasons to try to stabilise and share the Swift standard libraries. Having to ship them in every copy of every app has never been popular and not sharing them probably adds half a second to an apps initial startup time and wastes device memory. Also, I’ve no doubt internally Apple would like to start shipping System frameworks such as HealthKit developed in Swift to offer a richer API and the Swift team would like to be able to meet this requirement.
One way to implement this is to placing the Swift libraries at a new shared path and adjusting the applications “Runtime search path” (RPATH) to pick these up at runtime rather than in the app package as it is now.
/System
Library
Swift
libSwiftCore.dylib
HealthKit.framework
I wonder though would it be possible to introduce the concept of an “ABI stability window” where these libraries are versioned and Xcode would adjust the RPATH built into the application so apps built with different versions of Swift would use different versions of the shared Swift libraries. In this model the ABI would not be fixed forever (which is a very long time) but for the duration of the window.
/System
Library
Swift
4_2
libSwiftCore.dylib
HealthKit.framework
5_0
libSwiftCore.dylib
HealthKit.framework
These “Swift Version Packs” would accumulate over time and could be shipped with the Operating system or better downloaded on demand as part of the installation of an app by the “App Store” app. All the required information about which version of Swift is required and which System libraries are being used would be available load commands of the app executable or could be added as attributes in the application's Info.plist. AppStoreConnect requests to load .ipas from versions of the App Store app that have not been upgraded could inject the correct libraries into the app package at the server as before for backward compatibility.
Ultimately the granularity of the ABI stability window could be brought all the way down to Swift minor language versions (There are only a few a year) and the requirement for the concept of ABI stability simply melts away as applications would share the Swift standard libraries if they were compiled with the same version and not break if they didn't. There are a few details to work out but this would allow all the advantages of using shared libraries without impeding the future evolution of Swift or having to modify the operating system.