Dynamic Versus Static Framework in iOS
What is a dynamic framework? What is a static framework? Is one better than the other?
By the end of this blog, I hope you’ll have a solid understanding of the differences. I will also cover the reasons why we moved to dynamic frameworks in Mobile SDK 1.5, and the benefits. Finally, I will describe the advantages of using dynamic frameworks with CocoaPods (dependency manager).
WHY AND WHAT
Apple made dynamic framework to reduce the launch time of apps and their memory footprints. Dynamic framework also accepts assets inside the framework file, so you don’t have to create a separate bundle file to host files like images or screens (.nib).
Here is how Apple describes their dynamic framework:
“Two important factors that determine the performance of apps are their launch times and their memory footprints. Reducing the size of an app’s executable file and minimizing its use of memory once it’s launched make the app launch faster and use less memory once it’s launched. Using dynamic libraries instead of static libraries reduces the executable file size of an app. They also allow apps to delay loading libraries with special functionality only when they’re needed instead of at launch time. This feature contributes further to reduced launch times and efficient memory use.”
The following graphic shows how static libraries are all loaded into the address space for later use. As such, they become part of the executable, and are statically linked to client apps. This architecture makes apps slower to load and run.
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. This decreases the memory footprint for your app.
- Dynamic framework is exposed in the Xcode project build settings.
The only code change needed is the location of any assets that will reside inside the framework file. Your app is improved, even without recompiling.
- All system libraries in OS X are dynamic libraries, so app written for OS X automatically benefit. (This is how apps that use Carbon or Cocoa technologies benefit from improvements to OS X).
- Unlike static libraries, dynamic libraries are initialized when they are loaded; so they can perform clean-up tasks when client apps terminate normally. For details, see Module Initializers and Finalizers.”
Whenever we make changes to the SDK architecture, we always consider:
- Customer experience
- Backwards compatibility
- Supporting the latest OS releases
Clearly, the dynamic frameworks had some advantages over static libraries. When the dynamic framework was announced by Apple, we could have moved to dynamic it right away. But we believed that would limit our audience because dynamic framework is only available for iOS 8 and above. So, to maintain backward compatibility, we migrated from the old .a library to the new .framework model, but kept it as static.
We then focused on enhancing the customer experience by creating Xcode templates with predefined code for starting the SDK, folder structure, and project build settings to make getting started with a new project easier.
Another important improvement was to make our iOS Mobile SDK available in CocoaPods (https://cocoapods.org). (In the following section, you will learn how important having CocoaPods in place is for dynamic frameworks.)
Timing is everything. Recently, our customers using iOS 7 updated to iOS 9 or 10. Because iOS Mobile SDK always supports the latest two versions of the OS (9 and 10 as of this blog), now is the perfect time to move to dynamic framework.
There is one side effect of dynamic framework that makes the developer experience less than optimal.
Xcode produces two files whenever the framework is built:
- Simulator architecture file
- Device file
Apple suggests that developers deliver the two files to customers. But that means you need to add extra settings, or switch files whenever you want to test on the device or simulator.
To make a better experience, we built one .framework file with both simulator and device files. So you don’t waste time adding extra settings to the project, or have to switch files whenever you test the app in a different platform.
So what do you need to do to use our dynamic frameworks? Add them to your project via the Embedded Binaries’ section (project general tab) and before deploying your app to the Apple store, just add a custom script (copy and paste from the documentation in our website) to your app’s Build Phases, build it, and the simulator architecture will be removed from the framework as Apple requires.
For the most hands off experience, we highly recommend that you use the Mobile SDK with CocoaPods. All of the build settings and script is automatically handled by CocoaPods, so you don’t need to do anything at all.
For details of the Mobile SDK 1.5 release, see the Release Notes.