[swift-evolution] A case for postponing ABI stability

James Berry jberry at rogueorbit.com
Fri Jan 27 11:28:06 CST 2017

> On Jan 27, 2017, at 9:21 AM, James Berry <jberry at rogueorbit.com> wrote:
>> It would mean for Apple (and others who'd distribute compiled frameworks) to maintain several code bases of the same framework given that they would need to maintain backward compatibility and hence wouldn't be able to use new language features, etc. It's IMHO not that much about the technical constraint of having multiple binaries within the framework bundle as much as maintaining the code in a way that would compile under all Swift versions you'd like to support.
> Rather than Apple have to commit in perpetuity to ship all relevant versions of the frameworks, one could imagine more of an app-thinning/install-time optimization: “thinned” versions of apps would be built and signed without the shared system frameworks, but with dependency information recorded. At install-time, the app would be installed, and the working set of required shared frameworks on the device would be updated with any needed dependent frameworks. Thus only the set of frameworks required by installed apps would be present on device.
> This would require more app store, install-time, and perhaps dynamic linking, infrastructure, but would seem to solve the problem in a way that wouldn’t require ongoing development resources be applied to old versions.

i.e., you’re really just automatically factoring out frameworks that are common/redundant across apps in order to make install(ed) payloads smaller.

> James

More information about the swift-evolution mailing list