I suspect it's a hard issue for the App Store model.
You don't want a situation where someone updates App A, it updates a lib, then App B breaks because it hasn't been checked against the new library. I know you are a good developer who would check that, use major / minor library versions correctly etc. but there are lots of developers on the App Store. Or the fun case of updating App A, it updates a lib and then magical new features appear in App B that Apple doesn't like.
You'd probably have to use some sort of strict library versioning system where every app version is tied to a very specific library version. Are developers in general going to be disciplined enough to actually keep their apps all in sync on a specific version so older versions of the libraries can be removed? Or does this just mean every app from a developer will end up having its own slightly different revision of the lib tied to them? If it's the latter its probably not worth Apple's time adding all the complexity to manage the libraries to the App Store system.
And given that’s a new approach in a Unix-like environment, let’s call it Nix, and the content-addressed download location should probably be called the binary cache :)
[Not really, Nix integrates a build system into the process, and there was prior work I can’t remember that was binary-only and so closer, but the essence of the idea is very similar.]
And introduce a well known problem, not so well solved by OS makers and their developers outside Linux (somewhat). Windows and its developer community kept failing, it has improved in the recent years though, Apple decided long ago they would rather sacrifice space to guarantee a package will execute as intended. (even so, sometimes still fails as native libraries do change and aren't packaged). And upsell larger storage as highly profitable addons.
Maybe there is a dep linking pattern I'm unfamiliar with then. Afaik static linking, or packaging dependencies along with the main binary and dynamic linking or depending on libraries present on the system (with or without the integrated feature of conditionally fetching those prior to install/execution of that main binary) are the two battle tested approaches to distribute apps. The first duplicates stuff, the second leads to compatibility surprises when developers think version 12.1.6 of one of the hundreds of dependencies is compatible but in fact only tested with 12.1.3 and assumes semver is always honored, then poor user user on that just one dependency update is left with an app that crashes.
If you don't mind explaining what splitting a package and de duplicating the download is, and how it prevents the issue I mention that would make me learn something :)
You're thinking of a system that's too clever for its own good. Go dumber.
Start with a setup where you're packaging all dependencies with your binary, dynamically linked.
Then, instead of a single zip file, put each dependency in its own zip, or even each file in its own zip. But each release is still a full set of specific files. You never refer to a dependency by name or version. That's too clever and fragile.
If two releases of two separate programs happen to share the same exact file, then you only need to download it once.
Words like "compatible" and "semver" have no meaning to this system, because you only deduplicate the exact same file. You save space if a developer reuses code correctly, but otherwise there are no visible side effects and no bugs.
