Search code examples
iosxcodedynamic-linkingdynamic-library

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


I feel weird about difference between advantage of dynamic linking library in Window or Linux and iOS.

⬇️ sentences below are to prove why I feel weird.

I learned that library can divided into static library and dynamic library

Advantage of using dynamic library is allow other application to use same dynamic library ( in Window, .dll file) so that each of application memory usage can be reduce and it can be easiar to redistribute dynamic library rather than to redistribute application. Actually I could have experienced "there is no XXX.dll file" in using some applications

And in Xcode, when to create new project, we can choice framework and static library in framework & library. And after creating project, we can choice how to being what Mach-O Type is like "Executable, Dynamic Library, Static Library" etc..

So, I think that if I choice Mach-O type with Dynamic Library, the project will be compiled using dynamic linking library in linking way.

⬇️ I really wonder about.

  1. But like in Window, Could iOS user downloads .so file in their iPhone in order to work normally app or update dynamic library?
  2. Could others app launched in iPhone use same dynamic library ?

Because I could't experience about that.

  1. If it(1,2) can't be, why to use dynamic library even we couldn't get actual advantage of using dynamic library like in Window or Linux ?

Solution

  • 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