iOS Static VS Dynamic Frameworks Clarifications

iOS Static vs Dynamic frameworks clarifications

Before iOS8, Xcode only allowed the option of creating static libraries for iOS. The common problem with that was we had to ship the binary and headers separately.

Later, some developers came with the idea of creating 'static frameworks'. [the .framework is just a folder with symbolic links to the lib and the headers]. One such example is https://github.com/jverkoey/iOS-Framework

This option will work for iOS 7 or 8 or before that. Because they are just static libraries with the convenience of bundling the headers files along.

As for your questions of the resources, we would need to bundle them in '.bundle'.. For shipping them i am not sure if we can enclose them in the .framework folder.. In the past i used to ship my libs as a static framework and bundle...

However the above option will not work for you if you use Swift. Xcode does not support building static libraries that include swift code.

You must go with Dynamic frameworks if there is swift usage. In theory, Dynamic frameworks work in iOS7.. But, i think iTunes Connect will reject if the app is targeting iOS7 and uses Dynamic frameworks :-).

Hope this helps

iOS is it a static or a dynamic framework?

It can be either.

Only iOS8+ will allow dynamic frameworks in the app bundle, however.

The way to find out is to look in the .framework and use the file command on the main file:

$ cd iOS/Crashlytics.framework
$ ls -l
total 9984
-rwxr-xr-x  1 andy  staff  4710656 11 Sep 17:11 Crashlytics
drwxr-xr-x  8 andy  staff      272 11 Sep 17:11 Headers
-rw-r--r--  1 andy  staff     1553 11 Sep 17:11 Info.plist
drwxr-xr-x  3 andy  staff      102 11 Sep 17:11 Modules
-rwxr-xr-x  1 andy  staff   146164 11 Sep 17:11 run
-rwxr-xr-x  1 andy  staff   241688 11 Sep 17:11 submit
$ file Crashlytics 
Crashlytics: Mach-O universal binary with 5 architectures
Crashlytics (for architecture armv7):   current ar archive random library
Crashlytics (for architecture armv7s):  current ar archive random library
Crashlytics (for architecture i386):    current ar archive random library
Crashlytics (for architecture x86_64):  current ar archive random library
Crashlytics (for architecture arm64):   current ar archive random library

Where ar archive means "static library".

Alternatively, a "dynamic" framework will look like this and explicitly state that it's dynamically linked.

$ cd /Library/Frameworks/iTunesLibrary.framework/
$ ls -l
total 40
lrwxr-xr-x  1 root  wheel   24 10 Sep 17:38 Headers -> Versions/Current/Headers
lrwxr-xr-x  1 root  wheel   24 10 Sep 17:38 Modules -> Versions/Current/Modules
lrwxr-xr-x  1 root  wheel   26 10 Sep 17:38 Resources -> Versions/Current/Resources
drwxr-xr-x  4 root  wheel  136 10 Sep 17:41 Versions
lrwxr-xr-x  1 root  wheel   22 10 Sep 17:38 XPCServices -> Versions/A/XPCServices
lrwxr-xr-x  1 root  wheel   30 10 Sep 17:38 iTunesLibrary -> Versions/Current/iTunesLibrary
$ file Versions/Current/iTunesLibrary 
Versions/Current/iTunesLibrary: Mach-O universal binary with 2 architectures
Versions/Current/iTunesLibrary (for architecture i386): Mach-O dynamically linked shared library i386
Versions/Current/iTunesLibrary (for architecture x86_64):   Mach-O 64-bit dynamically linked shared library x86_64

iOS: When to choose a Cocoa Touch Static Library or Framework?

Some clarifications of Static vs Dynamic Frameworks: iOS Static vs Dynamic frameworks clarifications

Language: As for the use of Swift, before you couldn't create a Static Library with it, but from Xcode 9 onwards you can. So I guess Swift vs. ObjC wouldn't be a problem. Haven't found any tutorials on creating Static Libraries with Swift, just for creating Frameworks (for example: https://www.raywenderlich.com/5109-creating-a-framework-for-ios). So maybe a Framework would be easier in terms of finding resources/references.

dSYM: Citing an answer from an Apple Staff: "If you are building the framework as a dependency of your app target, the dSYMs for the framework will be present in the archive you create when archiving the app for distribution. If you are using a framework provided by a vendor that is already compiled, you will need to contact the framework vendor about the dSYMs." (https://forums.developer.apple.com/thread/70716). As for Static Libraries, they would be less work in terms of the dSYMs you handle. (Why does not Xcode generate dSYM for static library)

Codesigning for Frameworks: "Developer is free to distribute iOS framework without codesigning it as Consumer will re-codesign it anyway, but Developer is forced by Xcode to codesign their framework when they build for iOS device" (Creating iOS/OSX Frameworks: is it necessary to codesign them before distributing to other developers?)

As for Tests, adding the Framework or the Static Library on your Unit Testing target's build phases should do the job.

Breakpoints:
Static Libraries: Debugging a static library in Xcode
Frameworks: Xcode 9 - Framework breakpoints

For what I've read in the links, although Static Libraries might be a little more efficient, Frameworks are a lot less work to set up.

Why do we have this confusing setup about Static Library and Framework in Xcode

There are many concepts that must be clear

Libraries have two categories based on how they are linked to the executable file

1. Static library .a, .so. link at compile time. wiki
2. Dynamic libraries .dylib .dll etc. link at runtime. only apple can use it for iOS for some safe reason, we cannot build this.

ps, a special kind in apple platform

Text Based .dylib stubs — .tbd

Framework

Framework is a package that can contain resources such as dynamic libraries, strings, headers, images, storyboards etc.
vs Libraries, Framework has more features

Framework also has static and dynamic

iOS 8 later, we can use a dynamic framework, why Apple releases this. maybe Extension and App share code
this Dynamic Framework for iOS is named embedded frameworks, because when we build the app copy the framework in app bundle.
so the embedded framework is different from system dynamic Frameworks like UIKit.Framework

Why there's no "Dynamic Library" option?

the embedded library is allowed with the Framework option, but dynamic framework shared in muti app is also not allowed

Given that we can already link framework statically, why do we still need a "Static Library"? (isn't StaticFramework = StaticLibrary + Bundle? )

well, Xcode not only support Objective-c and Swift, but also support C, C++ which may use the static library

Does iOS lost most of the advantage of using dynamic frameworks?

You're correct in all of this. Non-system (i.e. not provided by Apple) dynamic libraries going to be less efficient in pretty much every way on iOS. They give you no space or memory savings, and they cost you at launch time.

The old Apple document you reference was almost entirely written before the iPhone. It's referring to late-loading libraries in Mac apps, which can help launch time.

On systems with shared libraries (or when using system libraries, which are shared on iOS), dynamic libraries save disk space, and can be shared between processes which saves memory and load time (because it's already loaded by some other process). But if you don't share the library, you can't really get any of those benefits. On systems that allow runtime loading of libraries (not iOS), dynamic libraries can delay the cost of loading seldom-used code, possibly indefinitely (if the code is never used). Furthermore, it opens up the opportunities for plugins and other extensions.

---

Related Topics