[babesh]

For iOS, there are the shared libraries provided by the OS. UIKit, PhotoKit, etc...

Shared libraries beyond that would bring the hell of version incompatibility. One need only look at Apple’s evolution of Swift where there still isn’t binary compatibility?

Most people don’t want to crack open their phone and set paths so that their app has a version of Python that works with it.

Also shared libraries can be giant security holes. See the bug in AFNetworking that affected many thousands of apps. Imagine an errant app shipping a backdoor into a shared networking library.

[pandalicious]

It's pretty telling that Linux distros are pretty much the only end-user platforms where binary distribution and packaging is built around shared libraries. Pretty much everyone else (Windows/OS X/iOS/Android/etc) generally expect binaries to include their own bundled versions of 3rd party libraries. Lots of people have looked at this problem and most have opted against the shared library approach.

[marcosdumay]

That's because Linux distros are more centralized that the Apple's walled garden. They just lack the walls, but are as much a garden as you can get.

Unless those platforms start distributing a huge number of libraries your software may decide do depend on, shared libraries won't take off on them.

[justinclift]

Not sure if "Linux distros" is the completely right term there. The various *BSD based "ports" systems do similar too.

[custos]

The Global Assembly Cache for .NET was supposed to be a shared library storage with support for multiple versions of the same library + signed assembly/hash matching.

It just never really took off for some reason. It's where all the BCL assemblies existed.

Instead we have NuGet and the libraries exist wherever the application is installed. GAC be damned :(

[toast0]

If Apple (or Google) wanted to make this work, it wouldn't be that hard. An app could list the dependencies, with a name perhaps, but definitely a hash. The developer would have to upload the dependencies, too. If the hash matched, the server would also do a byte by byte comparison, and if that matched, mark the dependencies as sharable. When downloading an app with a sharable dependency, the phone would check if it already had installed it, otherwise download it and install it at the same time as the app. Refcount the sharable dependencies at install/remove/upgrade time and rove unused dependencies after a reasonable time.

You would only get a benefit if two or more apps you installed used the exact same version of the dependency, but that seems like it might happen enough; especially once it's expected to be in the ecosystem.

[stickfigure]

Sounds like you just invented https://nixos.org/nix/

[on_and_off]

Google is actually working on this for the support libraries. All the Android apps use them, so it is a good target (and of course it might be possible to extend it to other libs). I guess it makes the most sense in the markets where data is very costly. By itself the support lib is not really big but if each KB counts, let's not download it several times.

[xg15]

> Shared libraries beyond that would bring the hell of version incompatibility

This is more a general question but I've never understand why so many shared library systems have the restriction of "only one version of a library". What stops you from storing different versions of the same library for different apps?

(I understand the problem with transitive dependencies - e.g. if the same app transitively depends on two different versions of a library, that might spell trouble. Even for this there are solutions - e.g. different classloaders for the jvm - but even without, you could disallow this special case witout sacrifying much)

[babesh]

For Apple libraries, it is because the latest framework could be providing a completely different implementation and they both want and need everyone on that implementation. For instance, they reimplemented Photos, introducing a new interface, maintaining the old interface but deprecating it.

Edit: in other words, common data.

[mtl_usr]

I guess they went as far as they could without a proper package manager.

> Shared libraries beyond that would bring the hell of version incompatibility. One need only look at Apple’s evolution of Swift where there still isn’t binary compatibility?

Since the source code is shared with Apple once it reaches the marketplace, wouldn't it be simpler for Apple to compile a specific version for whatever version of the Swift language is available on the target device ?

It wouldn't have any market value and wouldn't drive iOS devices sales but is would certainly slim them down a little.

> Also shared libraries can be giant security holes. See the bug in AFNetworking that affected many thousands of apps. Imagine an errant app shipping a backdoor into a shared networking library.

This sorta makes me like iOS a bit more. Memory gets cheaper but security doesn't get any cheaper when the dependencies grow.

[babesh]

Your source code isn’t shared with Apple. You ship Apple a binary or intermediate code.

Edit: Also doesn’t help if you have C or C++ code mixed in there.