I would love to have framework de-duplication work this way: - Each app ships with its own copy of the framework at a particular version. This ensures that app

I would love to have framework de-duplication work this way: - Each app ships with its own copy of the framework at a particular version. This ensures that apps can be installed offline, just as before. - When running the app for the first time, the OS moves the framework to a centrally-managed location. The new paths are assigned in a way that both preserves both the version names and prevents collisions of frameworks with the same name but that actually have different contents. For example, a version of Electron could be moved to /Library/SharedFrameworks/Electron/9.0.0-1234abc. This change alone makes it such that two apps using identical versions of a framework can share resources. - Each time the app runs, it tells the OS which version of the framework it's using. For apps that don't want to do anything fancy, this will simply be the version of the framework it shipped with, and the OS should take this to be the default for legacy apps. The key here is to be conservative -- the default setting should absolutely not cause more points of failure than if we didn't have this system. - But if apps want to do more deduplication and take advantage of extra features of newer versions of the framework that other apps might have installed on the system, they can do that. - Note: I think it's preferable to have an API that allows the app to request other versions of the framework, rather having the app specify a static dependency range. You don't know how apps might go about checking whether a newer version of a framework is safe to use. For example, maybe the developer wants the app to potentially check the newer framework version's hash against an online whitelist. This flexible solution allows for that. - The OS keeps track of the frameworks that the app last used. Once no app has last used a version of a framework, that version can be discarded. - Caveat: If an app allows the user to switch between multiple versions of a framework for some reason (e.g., LaTEX), it will tell the OS that it is using all of those versions. This will ensure that the version that isn't currently being used doesn't get discarded by the OS. - Bonus points: Apps can also use an OS-provided API to install new versions of a framework. But the API doesn't allow for explicit removal, since other apps might be using it. This also allows apps that always want to use the latest version of a framework to ship with a much smaller app bundle, and download the framework on first launch. (Chrome could probably benefit from this!) I wanted to write this out to (1) put together learnings I've gleaned from every previous time I've seen this problem brought up and (2) to point out how complex of a solution it would take to get this right. I think this would be way out of the scope of any framework and would be much better suited to be handled at the OS-level. This "framework-managing framework" could also potentially be a third-party library, but its functionality would probably trip up macOS's app checksumming, since frameworks would be removed from the app bundle.