> The vast majority of libraries on your system are used by only one program.
I find this is a Linux-ism rather than the common case on Windows or macOS. With Windows and macOS a given version of the OS is a fixed set of libraries and services available for third party software. Even third party libraries tend to call into the system libraries for some things. On Linux the only fixed facility of the OS is going to be kernel syscalls since even the libc can differ between distros.
I think dynamic libraries which are only used by a single program are even more common on windows and macos.
Look at how many DLLs ship with applications, and get installed inside the Program Files/MyApp directories! (Seriously - do a search for .dll files there. They're everywhere). Practically all of those DLLs are only be used by a single program. In each case, the price is being paid for dynamic linking (in startup time and the memory cost from not having dead code elimination). But with none of the benefits.
MacOS and iOS apps have the same problem - but I think the modern apple security policies make it even worse. As far as I know there's no way for a mac application bundle to install a shared library on macos or ios which is made available to other applications. The "Drag the .app to the Applications folder" requires that every application ships with its own set of "shared libraries". Outside of the shared libraries provided by the operating system, why would applications ever use shared libraries when they won't ever be shared anyway?
(If its not clear, I'm using the terms "shared library" and "dynamic library" interchangeably here because they mean the same thing.)
On Apple’s platforms the primary motivator for sharing code within an application is that an application isn’t just one component. You may have an application that has any number of app extensions in it that provide access to its features in various settings; if you build that functionality into a framework and use it from the app itself and any app extensions, it’ll still only be loaded into memory once even though there might be several processes mapping it.
Creating frameworks and libraries also helps the developer break down software into more testable components, which doesn’t necessarily require them to be dynamic but if you do go that route you remove an axis of variance that can result in different behavior.
For example, a static library on UNIX is just an indexed archive of object files, so it doesn’t have a single overall set of imports and exports or a single set of initializers to run at load, whereas a dynamic library is a fully-linked module with its own set of dependencies, imports, exports, and initializers. If you assume equivalence between them you’re eventually going to be wrong, often in hard-to-diagnose ways.
iOS developers have the choice of bundling shared code into a static library, or a dynamic framework, and the tradeoffs between them has historically been a little hard to determine, and have also been a moving target.
Some reasons to choose a dynamic library, even though it’s only ever consumed by a single app bundle:
* Shared code between apps embedded in the same bundle (see sibling comment)
* Some apps may want to load portions of code on-demand with dlopen()
* Dependencies / duplicate symbols. Common example is an analytics static library that contains sqlite, and either the main app or another library also linking sqlite, and getting link warnings about “duplicate symbols, which one is used is undefined”. I think this isn’t necessarily a static / dynamic library issue, but 3rd party static libs were often a “single file with all dependencies” and didn’t always understand why that was a problem.
* for a long time, it was the cleanest way to provide & consume headers & object file when distributing closed-source 3rd party libraries.
There may be more, I’m fuzzy on some of the details. If I remember correctly, some of the reasons could be considered tooling issues: creating a Framework was easier for some cases, even if you didn’t want/need the dynamic linking inherent in that choice.
I find this is a Linux-ism rather than the common case on Windows or macOS. With Windows and macOS a given version of the OS is a fixed set of libraries and services available for third party software. Even third party libraries tend to call into the system libraries for some things. On Linux the only fixed facility of the OS is going to be kernel syscalls since even the libc can differ between distros.