[swift-evolution] A case for postponing ABI stability

[Chris Lattner]

> On Jan 27, 2017, at 11:27 AM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 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.

These are the benefits of ABI stability that I can see [**]:

1. Not shipping the stdlib with your app reduces its download size.
2. 3rd party developers could someday ship binary packages/frameworks.
3. Apple could choose to ship OS frameworks with “Swift only” enhancements (e.g. a method that takes an "Int?” argument).

That said, I think that these wins are often overstated and poorly understood.  

On #1, as you say, there are lots of ways to reduce the impact of the Swift stdlib size in general, and a lot of the work on ABI stability pushes towards this.  As it is today, the overhead is only a few MB anyway (not the 10’s of MB that people think by looking at the size with bitcode included) because of how “app thinning” works.  Further, if some version of iOS “N” included the stdlib, your app would still need to include the stdlib if your app needs to deploy backwards to "iOS N-1”.  There are other things that could be done that would have a huge benefit, like merge all the overlay dylibs + Swift stdlib together into one large dylib.  This would improve app launch time independently of ABI stability.

On #2, as Michael’s document indicates, this requires stabilizing the ABI *and* the module file format.  The second clearly isn’t in scope for Swift 4, so it isn’t really a motivator for this.  Also, adding a binary-only dependency to your App is always a risk thing.

On #3, it isn’t a truly great solution, but the existing overlay mechanism has been proven as a way to ship substantial Swift-only enhancements to the OS.  In Swift 3, Foundation included major enhancements including entirely new types like Data.  It has additional advantage of allowing backward deployment of this functionality.


In short, in the Swift 4 / iOS "N" timeframe, the only benefit of ABI stability would be that apps don’t need to include the standard library if they deploy to iOS "N or later”.  Independent of whether ABI stability is achievable, I think it is important to do things like merge the dylibs together, since backward deployment will continue to be important for many apps.

-Chris

[**]  Just a note, but I don’t think that any of these apply to Linux or other non-Apple platforms supported by Swift.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170127/56f02caf/attachment.html>