Or iOS may load it later when iOS actually need the framework?
The Wikipedia page on dynamic linking covers both the general idea and a number of details specific to various popular operating systems. It says (in part) this about Darwin, including macOS and iOS:
The executables on the macOS and iOS platforms often interact with the dynamic linker during the execution of the process; it is even known that an executable might interact with the dynamic linker, causing it to load more libraries and resolve more symbols, hours after it initially launches.
Furthermore, if you read the man page for dyld
, the dynamic loader, you'll find an environment variable called DYLD_BIND_AT_LAUNCH
that is described thus:
When this is set, the dynamic linker binds all undefined symbols the program needs at launch time. This includes function symbols that can are normally lazily bound at the time of their first call.
A final piece of evidence is in Apple's Overview of Dynamic Libraries document, which says in part:
When an app is launched, the OS X kernel loads the app’s code and data into the address space of a new process. The kernel also loads the dynamic loader ( /usr/lib/dyld ) into the process and passes control to it. The dynamic loader then loads the app’s dependent libraries. These are the dynamic libraries the app was linked with. The static linker records the filenames of each of the dependent libraries at the time the app is linked. This filename is known as the dynamic library’s install name.
And in the next paragraph:
The dynamic loader resolves only the undefined external symbols the app actually uses during the launch process. Other symbols remain unresolved until the app uses them.
Given all that, it sounds like iOS probably loads each dynamic framework as part of the process of launching an app, but defers actually binding undefined names in the app to definitions in the framework until it's actually needed.