Static VS dynamic frameworks in Swift: an in-depth analysis

There has been quiet some discussion lately in the Swift community about the benefits of using static instead of dynamic frameworks (see 1, 2, 3). I was specially interested in this post, that explains how switching from dynamic to static frameworks can cut your app’s launch time in half.

I decided to test this by myself. The app I am working on at the moment depends on a total of 27 dynamic frameworks, 6 consumed using Carthage and 21 through CocoaPods.

The first two sections of this post explain how I generated static frameworks with Carthage and CocoaPods. The third one shows the results I got, in terms of app size and launch times. If you are just interested in the conclusions, scroll to the bottom.

Generate static frameworks: Carthage

In order to generate static frameworks using Carthage, the Xcode projects under the folder have to set the build setting to . Using this and this as a reference, I came up with the following script:

  • The two first lines generate a temporary file with the build setting set to .
  • The third line sets the path to the temporary file in the environmental variable. overrides the build settings of the Xcode project with the ones found inside the .
  • The fourth line runs Carthage, which uses under the hood to generate the frameworks, and then places the static ones under the path .

Using this method there is no need to modify the Xcode projects found under .

Generate static frameworks: CocoaPods

In order to generate static frameworks using CocoaPods, the file has to set the specification to , as explained here. To simulate this without making modifications to the files, it is possible to add a preinstall step to the , as explained here:

The results: app size and launch time

I managed to switch 25 out of the 27 dependencies to static frameworks. In order to measure the app size, I archived and exported it as a build. In order to measure the launch times I set the environmental variable to , as explained here.

App size

These are the results:

Launch times

The launch time tests were performed running the app from Xcode using the configuration, on an iPhone 8 with iOS 12.1.1. In order to get a better understanding of the results, I ran the app 15 times:

  1. Before the first run, the device is rebooted to clear the dyld cache, and a fresh installation of the app is done.
  2. Before the 11th run the device is also rebooted to clear the dyld cache (but a fresh installation of the app is NOT done).
  3. Runs 2nd to 10th and 12th to 15th happen without rebooting the device, and without doing a fresh installation of the app.

These are the results, where the total launch times can be visualised in the first graph, while the second graph shows the time spent in each of the four launch steps. The results for runs 2nd to 10th and 12th to 15th are averaged:

Launch times when using static VS dynamic frameworks

Conclusions

Note that the analysis done here is on an app exported from Xcode, and not the final app downloaded from the AppStore, which can go through further optimisations before ending up in the users’ phones. The main conclusions that can be obtained from these results are below:

  1. Using static frameworks instead of dynamic frameworks reduces the app size, in my case by a moderate 14.55%. Most probably this is due to the compiler being able to remove unused symbols, which is not possible when using dynamic frameworks.
  2. Using static frameworks instead of dynamic frameworks reduces app launch time considerably. In my case the improvements are between 28% and 47%.
  3. The dyld cache alleviates the slow launch times, but only after the first run of the app. Still, using static frameworks instead of dynamic frameworks leads to better performance. Furthermore, relying on the dyld cache may not be a good idea, as it is not possible to know for how long it is kept around before it is cleared out.

iOS developer @Revolut

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store