> On Jan 27, 2017, at 11:27 AM, Tino Heth <[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.
> 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".
> On Jan 27, 2017, at 2:21 PM, Greg Parker via swift-evolution
> <[email protected]> wrote:
> You can't simply freeze an old version of a framework. Many app frameworks
> have interfaces with other OS components. Freezing the app side of the
> interface also constrains the other side, effectively introducing another
> piece of ABI that must be kept stable.
>
> For example, CoreGraphics needs to talk to the window server. If you try to
> freeze some version of CoreGraphics then you require the window server to
> implement that particular interface forever. Now the window server's private
> interface has become an ABI that must preserve binary compatibility. The same
> is true for the spellcheck server, the pasteboard server, the address book
> database server, and a great many others.
Greg’s words from upthread are instructive. The current interface between app
bundles, and the rest of the system, is currently limited to the C/Obj-C ABI.
While the idea above could potentially allow you to factor common libraries out
of the apps we have today, those libraries, and the apps themselves, would
still be limited to the C/ObjC ABI to speak to the rest of the system. To have
any prayer of being able to have apps call into more modern, and non-objc,
Swift frameworks in the rest of the system, you need to have a stable ABI for
swift. So the idea might work for the apps of today, but it doesn’t do much to
enable the apps (and system frameworks) of tomorrow.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
