> On Jan 27, 2017, at 11:27 AM, Tino Heth via swift-evolution
> <[email protected]> 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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
