A library is a collection of resources and the code itself, compiled for one or more architectures. Apple provides 2 types of library architectures that behaves differently upon building our app.
Static libraries (*.a) :
When the app launches Static libraries loaded into address space for future use. They become part of the executable, and are statically linked to client apps. Thus, it (especially large executable libraries) makes apps slower to load and run, even launch time of the apps.Apple shown the architecture of static libraries as below :
Dynamic libraries (*.dylib) :
With dynamic libraries, the app loads code into its address space when it’s actually needed, either at launch time or at runtime. The libraries are not part of the executable file. Thus decreases the memory footprint for your app.Clearly dynamic frameworks has got more advantages over static frameworks. Notably, it is available for iOS 8 and above.
Apple shown the architecture of dynamic libraries as below :
Developer involvement:
Xcode produces 2 files when Dynamic libraries are build -
- Simulator Architecture file
- Device file
Note: The target architecture of the client and the dynamic library must be the same. Otherwise, the dynamic loader doesn’t load the library.
So what do developer need to do to use our dynamic frameworks?
We can add them to our project via the Embedded Binaries section (project general tab) and before deploying app to the Apple store, just add a custom script (copy and paste from the documentation) to your app’s Build Phases, build it, and the simulator architecture will be removed from the framework as Apple requires.
For make developer life easier, it is highly recommend CocoaPods. All of the build settings and script is automatically handled by CocoaPods, so you don’t need to do anything at all.