Why should I create Dynamic frameworks for iOS Project?

Question

I have main application target. And I'm moving some code into frameworks to reduce compile time of the huge project.

Default framework type is Dynamic (BuildSettings -> Mach-O Type). I understand benefits of using Apple's dynamic frameworks as several apps will use the same framework and each application size will be lower (because the app size doesn't include this dynamic frameworks).

But if I'm using my own frameworks and only in my application, why should I choose dynamic frameworks.

1. It looks like the app size will be bigger with dynamic frameworks Source and application start time will be longer (because it needs to connect all these dynamic libraries, but with static they are already a part of app executable).

2. App store size probably will be bigger as well with dynamic frameworks as well.

Would be helpful if somebody can fill me in what benefits can we get using dynamic frameworks

Answer 1

Your assessment is mostly correct.

It is possible to not directly link against frameworks, but instead load them on demand with dlopen.
This can be used both for a plugin system where only one of many available libraries will be needed, or to defer the loading of particularly heavy frameworks, which would actually reduce the launch time of your app.

Further reasons I can think of for using dynamically linked frameworks are:

• Licensing reasons.
• If you're developing a closed-source library for other developers to use, then a static library normally has a lot more information still embedded than a dynamic library and with a static library you can easily conceal the fact that you're using it, both of which you might not want.
• If you have symbol clashes (e.g. due to linking against a static library multiple times, as might be the case with the Rust standard library), then you can split the different codebases into frameworks in order to separate the namespaces.