The first impression of any App is how fast the app is opening. When a User downloads an app from the AppStore all he cares about is: just click on the App Icon from the Home screen and experience everything the app has to offer as quickly as possible. So, the App Launch time will be minimum for the apps.
Let’s analyze the problem statement, and to begin with we need to first understand the type of App Launches:
Let’s analyze the type of App Launch timings and see what we can do to make it better.
Coming back to the iOS world; The App launch time can be bifurcated into two:
This is the time before the
UIApplicationMain is returned. Or to simply say, when your Application’s
main() method is called and you get the control on the App by the OS. And you already must have realized so far, since this time is not in your control hence difficult to manage. However, dyld has a built in measurement(An environment variable:
DYLD_PRINT_STATISTICS) to analyze this. Which is as depicted in the snapshot below.
And as you must already noticed the build configuration should be set to
Release for the calculation, because this is the configuration with which the app will be released on AppStore. Also, it’s always recommended to do this exercise on an iPhone instead of a simulator. Once the configuration is done and the app is run, you would see the pre-
main() timing details on the console something like this:
This data gives you an abstract idea about what it could be in your app that causes it to launch slowly. To know in depth about each of these types, I would recommend to watch the WWDC 2016 talk on Optimizing App Startup Time.
As mentioned in the talk the major reason for your App slow startup time could be the use of multiple dynamic frameworks. While Apple recommends to use only 6, but realistically speaking as your app includes more and more features, you tend to have multiple frameworks. Also, as you must already have been using Swift for your applications. Each application has to ship with the Swift standard libraries
Well, I believe these libs must be already optimized by Apple, but they still do exist. However, this is not in your control until we’ve complete ABI stability for Swift. Starting with Xcode 10.2 and iOS 12.2 the Swift standard libraries will no longer be shipped with the apps. This would reduce the thinned IPA size by ~9MB.
That being said the first and most important thing that you should consider doing is: Check for all your dependencies and if possible merge as many of them possible without breaking the logical boundaries of your application. The second step is to convert the dependencies to
Static Frameworks instead of
Xcode 9, it was not possible to ship Swift frameworks as Static frameworks, but fortunately,
Xcode 9 beta 4 onwards has ABI Source Compatibility, which gives you the flexibility to ship Swift Frameworks as Static Frameworks as well. All you need to do is just change the Build settings of the Framework target(s) as:
Please note this applies true for both Pure Swift frameworks as well as Frameworks which has both Swift and Objective-C in them.
Just by merging the frameworks and converting them to Static Frameworks you would see a great difference before and after for the pre-
main() launch time of the application. A simple illustration is shown below with 4 Framework dependencies:
While this should help you win
90% of the battle related to the pre-
main()launch time of the app, the rest is related to coding best practices as illustrated in the WWDC talk.
Not only does static frameworks improve the app loading time, but they are also beneficial for the overall size of the app as well.
Moving on to next…
This factor is something which you as a developer will have full control. Hence, this is very deterministic and easy to understand and manage. This starts with
application:didFinishLaunchingWithOptions of your
AppDelegate all the way up to the ViewController(s)
viewWillAppear methods is when your User can see the “Welcome/Home” screen of your App.
The simple equation comes out to be:
pre-<code class="markup--code markup--pre-code">main() time</code> + post-<code class="markup--code markup--pre-code">main() time = Total time of App Launch</code>
That being said, all of the above-mentioned strategies should be religiously check listed for every release of your app in order to have a better experience for the Users and hence maximum retention of your product.
Be the first to comment.