> On Jan 27, 2017, at 9:21 AM, James Berry <[email protected]> wrote: >> It would mean for Apple (and others who'd distribute compiled frameworks) to >> maintain several code bases of the same framework given that they would need >> to maintain backward compatibility and hence wouldn't be able to use new >> language features, etc. It's IMHO not that much about the technical >> constraint of having multiple binaries within the framework bundle as much >> as maintaining the code in a way that would compile under all Swift versions >> you'd like to support. > > 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 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.e., you’re really just automatically factoring out frameworks that are common/redundant across apps in order to make install(ed) payloads smaller. > > James > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
