Search code examples
iosframeworkslaunch-timedynamic-frameworksstatic-framework

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


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

Does it mean if we use dynamic frameworks with dlOpen to load them later, it will be faster than static frameworks? Because the dynamic frameworks take some time to link in the begining, but they save more time in loading into memory. And loading time of static frameworks is greater then the linking time in dynamic frameworks. Is that true?

So it looks like there is none adavantage of using dynamic frameworks on iOS, right?

And how about on macOS and Linux? Do dynamic frameworks have any advantage? If so, how do they work?


Solution

  • 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.