Can You Build Dynamic Libraries For iOS and Load Them At Runtime

Can you build dynamic libraries for iOS and load them at runtime?

At the time this question was asked, Dynamic libraries were not supported by iOS and will result in your app getting rejected. Only static libraries are allowed.

However, in iOS8 you can use dynamic libraries and frameworks. It should "just work"

When to use dynamic linking library in iOS ? And what is advantage of using dynamic library in iOS?

Your understanding of dynamic and static libraries is correct.

Static Linking

The compiled source code (object code, the .o files) and the compiled library code are combined into a single executable [1]

Dynamic Linking

The compiled source code (object code) and the library code are not combined together. The references to the dynamically linked library are resolved at runtime while the app launches or while running (the second part is not applicable in the case of iOS Apps) [1]

Q1

iOS borrows heavily from MacOS on how its applications work. Executables in both the OSes are Mach-O files. Now, on macOS dynamically linked libraries or dylibs are intended and designed to be updated without having to update the entire app. And by design, this is possible in iOS as well. What prevents this is Apple's guidelines restricting apps from downloading executable code from the internet. Any new update has to go through their review process. [2]

Q2

Yes, some dynamically linked libraries are shared across apps. However, they are created and updated by Apple through iOS updates. All Apple frameworks like UIKit, SceneKit, etc are examples of this. This is why these frameworks are weakly linked in Xcode with the option 'Do Not Embed'

Q3

Using your own dylibs are not completely pointless. If you ship extensions in your app, then dylibs are an excellent option to share code between the app and extensions without increasing the binary size. In this case, the executables share the same library. [3]

[1] https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html#//apple_ref/doc/uid/TP40001873-SW1

[2] https://developer.apple.com/app-store/review/guidelines/#app-completeness#2.5.2

[3] https://developer.apple.com/forums/thread/73802

can I use dynamic library(shared object) in my iphone app?

As Bernardo Ramos states in a comment: "Since iOS8 we can use dynamic libraries".

Dynamic libraries are not allowed by the App Store. No code may be loaded at run-time. The answer is to convert them to static libraries and compile them into the application.

From iPhoneOSTechOverview:

"If you want to integrate code from a framework or dynamic library into your application, you should link that code statically into your application’s executable file when building your project."

Read "should" as "must"

See SO Answer: Can create dynamic library for iOS?

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.

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

---

Related Topics