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