<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 27, 2017, at 11:27 AM, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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.</div></div></blockquote></div><br class=""><div class="">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 ;-):</div><div class="">What is the main motivation for ABI stability?</div><div class="">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.</div><div class="">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".</div></div></div></blockquote></div><br class=""><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">On Jan 27, 2017, at 2:21 PM, Greg Parker via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div></div></blockquote><br class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote></div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">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.</div></div></div></div></body></html>