> 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".
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
