iOS: SDK distribution as Framework Vs Static Library

Suppose we have App1 and App2 having our framework (code signed), then will iOS take care of maintianing a single copy of framewok in the disk? (assuming both are using same set of interfaces and versions)

Is there a option to publish this framework as a shared API service?

Every app is self-contained, with the framework living inside of the app bundle for each app that needs it. As you noted, sharing a framework outside of its containing app is not possible.

My question is with the App sandboaxing in place (each app having framework in its bundle), how it make sense to have frameworks.

It makes sense from a code modularity and build perspective. If your suite of apps has core functionality used in each app, then you can factor that code into a framework target, and configure all of your apps to depend on that framework instead of having that code reimplemented for every app. It's the exact same reason for using framework to share code between the app and any app extensions within that app.

Hi Edford,

Many thanks for proviing information. Few clarification needed to decide on distribution mode of our SDK.

It makes sense from a code modularity and build perspective. If your suite of apps has core functionality used in each app, then you can factor that code into a framework target, and configure all of your apps to depend on that framework instead of having that code reimplemented for every app.

>> Is it not true in case of static library too?

If app extension in not in scope, then should we prefer static library as app using it would have lesser disk image as compared to frameworks.

Does below concept does not apply to iOS custom frameworks? I mean at run time, two Apps using the same custom framework (with same version) will load their own copies of framework or they share the same copy?

image URL: url

<< image courtesy Apple documentation>>

>> Is it not true in case of static library too?

Static libraries also acheive code modularity when shared across multiple app targets, yes.

>> If app extension in not in scope, then should we prefer static library as app using it would have lesser disk image as compared to frameworks.

It depends on your needs. Frameworks are nice because they wrap up any resources the framework depends on, simplying integrating them into apps. Within a single app that might have multiple binaries (an app executable and several app extensions), frameworks can reduce the size of an app, because common code is represented once, in a framework, instead of in each binary, as would be the case for a static library. However, if you have a lot of frameworks, the cost to the launch time of an app can be significant. Discussion of these costs is covered in the WWDC 2016 Optimizing App Start Up Timepresentation.

>> I mean at run time, two Apps using the same custom framework (with same version) will load their own copies of framework or they share the same copy?

Each app loads their own copy of the framework.

Thanks edford for clarifing clouds.

Just for my curitosity,

"Only one copy of a framework’s read-only resources reside physically in-memory at any given time, regardless of how many processes are using those resources. This sharing of resources reduces the memory footprint of the system and helps improve performance."

in the What are Frameworks? is applicable only to OS X not iOS?

That is applicable on iOS as well.