[swift-evolution] A case for postponing ABI stability

Tino Heth 2th at gmx.de
Fri Jan 27 13:27:18 CST 2017


> 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 the 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'm thinking in the same direction… but although this isn't trivial, it still sounds to simple to be a solution for the dreaded problem of unstable ABI, so I can't fight the feeling I'm missing something important ;-):
What is the main motivation for ABI stability?
Sure, it would reduce app size, and this could be achieved with with this approach as well — but nowadays many apps are so bloated that 10MB make no real difference.
Declaring a stable ABI is also a statement of maturity (I don't care much about that, but others might feel different), and there might be other goals I'm not even aware of, and which cannot be reached with "tricks".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170127/b982b725/attachment.html>


More information about the swift-evolution mailing list