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.

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.

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.

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

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 :(

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.

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

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.

> 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)

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.

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.

> isn't it possible to bundle some dynamically loaded libraries that can be shared by multiple apps

Yes, there is one: the standard library, provided by Apple. However, many apps eschew this to use their own libraries and frameworks for whatever reason, be it ease of use or feature enhancements, and these cannot be shared.

The Facebook API library provided by Facebook is notoriously huge in source code at least, and they're pretty proud of the size of it, can't find the link right now, but they had a blog post talking about it a few years ago ago.

Here's a link to the oft-mocked slides from the talk where a Facebook engineer spoke about how iOS can't handle the scale of their app because they do the very logical thing of using over 18,000 classes: https://www.columbia.edu/~ng2573/zuggybuggy_is_2scale4ios.pd...

It would have to entirely app stored manage - it's not possible for iOS developers to currently share code between apps.

Everything that is shared between apps currently is stuff that's provided by the shared platform.