I've got an iOS app that links to 15 Apple frameworks (including the ~3 basic ones every app uses). I've noticed that my app's load time, and time restoring from the background, is pretty high, though the executable is only 600kb. Could all these frameworks be the cause of the load time issue? And is it possible to, say, lazily-load frameworks as needed?
Yes dynamically linked frameworks do affect load time, you can see this in instruments using the time profiler. You should see dyload running as your app launches and it will take time to load in each framework.
Even worse if have static code in something like +initialize this will run at load time too, further slowing your app.
Related
Does iOS lost most of the advantage of using dynamic frameworks?
Since iOS will copy all the dynamic frameworks needed into the app bundle, it doesn't share dynamic frameworks between apps and save memory. Except for sharing memory with the main app and its extensions.
App using dlOpen can not ship to App Store. Which means Apple disallow dynamic framework from being used officially.
The old Apple document says dynamic frameworks save app launch time, but the new document says they don't. Is the old document outdated?
Here is the comparision:
make the app launch faster and use less memory once it’s launched
Load fewer dynamic libraries. This can be one of the longest parts of an app’s total launch time. Apple recommends using only up to six non-system frameworks
See if you can remove any of the dynamic libraries you’re using by replacing them with static versions or compiling their sources directly.
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?
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.
I want to present a ViewController from a framework which is downloaded later in the app document directory (Something like Microsoft Code-Push in React Native).
Be more specific: I want to install an app (in React Native, Swift, etc) then it would download another swift(objc) compiled app and run it in the next startup.
(I don't care about the first app but It's critical to run a swift compiled code.)
As you have now learned in the comments, you cannot download and "run-on-the-fly" compiled code.
A couple thoughts though...
As you are trying to "get around Apple's review process" you should be aware that any method you use to change your app after approval can be risky.
Whether it's downloading graphics, updated data files, config files to change appearance or functionality, using Cordova or React Native (as with Code-Push), etc - minor changes are fine.
Data updates, new imagery, etc. Even layout changes handled by your internal code are no big deal.
However, making major changes, particularly when it is obviously done to get around initial rejection, will end up resulting in your account being banned if/when you get caught.
As in the Appole doc
it states that:
If you are building your own static library and using shell scripts to
package it in a .framework directory, you need to migrate to building
a framework with a dynamic library instead, as this is the correct way
to build a framework. Static frameworks are not a supported way of
sharing static libraries.
Why Apple disallows static library in a framework?
And is it a contraction of this post ?
Or maybe that post confuses static library and static framework?
All frameworks in iOS are dynamic, right?
Apple said:
A framework is a hierarchical directory that encapsulates a dynamic library, header
files, and resources, such as storyboards, image files, and localized
strings, into a single package. Apps using frameworks need to embed
the framework in the app's bundle.
A static library has to be loaded when app launches, without considering wether if its required right away or not. At the other hand a dynamic library is loaded only when it is required, hence improving the launch timings of the app and decreasing the memory pressure of the phone.
As an example consider I am using an e-commerce app which also allows to scan barcode and give details about the products. Now when I launch the app, I won't need the barcode functionality rightaway. I need to land inside the app first and start shopping. When I need to scan some barcode, I am happy to wait and let the framework loaded then but not at the start of the app.
Here is how Apple says this in its documentation:
Two important factors that determine the performance of apps are their launch times and their memory footprints. Reducing the size of an app’s executable file and minimizing its use of memory once it’s launched make the app launch faster and use less memory once it’s launched. Using dynamic libraries instead of static libraries reduces the executable file size of an app. They also allow apps to delay loading libraries with special functionality only when they’re needed instead of at launch time. This feature contributes further to reduced launch times and efficient memory use.
Documentation link: https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html
When launching my app i get the launch screen for about 2-3 seconds and only then my first UIViewController appears.
And some times my ViewDIdAppear is being called before the UIViewController is actually appearing.
I have a pretty big storyboard (15 screens).
I have some flags that i check from UserDefaults (user is logged-in ...), and i initialize crashlytics and GCM.
So the flags and the initializing doesn't seem to be the problem.
I checked system time differences and it seems to be OK.
Any ideas for debugging the slow launch?
In Xcode: Product -> Profile
Choose the "Time Profiler"
Running this tool will give you time spent in every method in your program, and it'll give you that information in a hierarchical structure. This should give you an idea where most of the time is spent. Keep in mind that the instrumentation adds extra overhead, so the absolute time value may not be correct, but the proportion of time spend in each method should what you need to debug this issue.
Here is a decent looking tutorial (albeit on an older version of Xcode) showing how to use this tool.
The time profiler will not help you if the slowness is from the initialization time. During that time none of your code is running yet, so the time profile won't be logging anything.
You can have xcode print out stattics on how long it take to launch by going to 'edit scheme' -> run -> environment variables add add DYLD_PRINT_STATISTICS with a value of 1. Ideally you want your launch time to be less than 400ms which is about the length of the opening animation. I was able to cut my launch time in half by removing use_frameworks! from cocoapods. And I was able to to cut it in half again by removing unused external libraries.
There is a great apple lecture on the topic here:
https://developer.apple.com/videos/play/wwdc2016/406/
I've developed an iOS 5 application with a rather large cache stored in /Library/Caches. I've noticed that running the app on an actual ipad is getting very slow. As in 5 minutes or so just to launch the application. Without Xcode, the application launches quickly. There seems to be a correlation between the size of the cache and the amount of time it takes to run the application, as the application starts quickly with a minimal cache.
I'm assuming that Xcode is making a backup or something silly like this. Has anyone else experienced this, and if so is there a workaround?
EDIT: (for clarity)
The structure of /Library/Caches/ is:
./big_ass_image1.png
./big_ass_image2.png
...
./big_ass_imageN.png
I simply read them in with coregraphics at a later time. The issue is the speed at which Xcode actually runs my app on the ipad. It's upwards of 4 minutes, which makes on device development very difficult. I would use the simulator, but it's precisely these big data sets that need to be tested on device.
EDIT: (how the files get there)
The files get into the cache via downloading. And sadly, there's no way to limit the cache size (at least not at the 2 gigabyte level).