Cold, Hot, and Warm App Launch Times and their impact on user engagement

Hey folks,

I hope you are doing great and writing beautiful apps helping people to bring their ideas to mobile.

Target Audience

I am writing this article for general mobile apps experience but the example, references will make it android specific but this article is purely mobile-specific.

Agenda

The agenda of this article is to understand the difference between these three terms mentioned in the title of this article, benchmark time, some stats explaining user engagement, and last but the most important best practices for each type of app launch.

Let's talk about these launch types in detail

Usecase

Hold your android mobile, clear everything from app stack (minimized) apps. Click on your app icon from home. Everything will be initialized from zero.

What does OS do for us?

After the app process creates your activity, the activity performs the following operations:

1. Initializes values.
2. Calls constructors.
3. Calls the callback method, such as Activity.onCreate(), appropriate to the current lifecycle state of the activity.

Typically, the onCreate() method has the greatest impact on load time, because it performs the work with the highest overhead: loading and inflating views, and initializing the objects needed for the activity to run.

Usecase

Hold your android mobile, clear everything (minimized apps) from the app stack. Click your app from the app launcher and make a fresh app start. This will bring your app in the foreground. This was so far a cold start. Now press the home ◯ button from your mobile, your app will go into a paused state. Now press the app switcher button ▢ and bring back your app to the foreground. This process will bring back your app to the last state where you left without reinitializing any of the app assets.

During this process with your app if activity got killed by OS due to onTrimMemory or any other reason, it will not be considered as HOT start

What does OS do for us?

A hot start of your application is much simpler and lower-overhead than a cold start. In a hot start, all the system does is bring your activity to the foreground. If all of your application’s activities are still resident in memory, then the app can avoid having to repeat object initialization, layout inflation, and rendering.

However, if some memory has been purged in response to memory trimming events, such as onTrimMemory(), then those objects will need to be recreated in response to the hot start event.

A hot start displays the same on-screen behavior as a cold start scenario: The system process displays a blank screen until the app has finished rendering the activity.

Usecase

Hold your android mobile, clear everything (minimized apps) from the app stack. Click your app from the app launcher and make a fresh app start. This will bring your app to the foreground. This was so far a cold start. Now press the home ◯ or back ◁ button from your mobile, your app will go into paused/stop state. You leave your device and forget you were working with an app or you were watching a movie that was buffered 50%. Now there are two cases. if you come back after pressing the back button, your app will restart, that's obvious. What will happen if you pressed the home button ◯ last time? It may start from the last case (ideally) but what if I tell you when you were away or started a new app from the app launcher, OS was running short of memory and acquired some memory from your paused app. It will force your current screen to reinitialize.

So what happened in the background? Some of the resources were initialized and a few were already in memory when your app came back into view (Foreground). This state is in between Cold and Hot app start. So it is called a Warm start ;).

What does OS do for us?

A warm start encompasses some subset of the operations that take place during a cold start; at the same time, it represents more overhead than a hot start. There are many potential states that could be considered warm starts. For instance:

1. The user backs out of your app, but then re-launches it. The process may have continued to run, but the app must recreate the activity from scratch via a call to onCreate().
2. The system evicts your app from memory, and then the user re-launches it. The process and the activity need to be restarted, but the task can benefit somewhat from the saved instance state bundle passed into onCreate().

Best benchmark times for each launch time?

Google says ideal benchmark time should be

1. Cold startup takes 5 seconds or longer.
2. Warm startup takes 2 seconds or longer.
3. Hot startup takes 1.5 seconds or longer.

So whenever you are writing your apps always consider these launch times and compare them with your app. Benchmarking your app’s launch time is very vital for any business.

Why launch time is so important for your app/business?

First impressions are so important when it comes to mobile apps. if your first impression is the slow user may not use your app for the next time and will check your competitor who takes care of launch time so he will grab your one-time visitor. This is a failure for your team, project, and investors.

Let’s talk about some stats available on the internet showing 60% of users won't use your app next time if it's slow :( this number is huge. Every 6th person from ten users will leave your app. That is a real loss considering that Cost Per Install (CPI) is not cheap at all. if that is the case, your team failed to bring those users to the conversion, and you have wasted 60% of your user acquisition costs.

So the loss is not ending here, this one bad impression on your app will lead your other products’ decline as well. Studies suggest that more than 50% of users will be reluctant to use your other products if they had an issue with one of your products. So the impact of the bad experience is huge and may lead to disaster, and drive business to your competitors.

Worse still, your loss will be to someone else’s benefit.

What are the key points to improve the app launch time performance?

There are a few key points in your app that must be considered very efficient in order to achieve the threshold time of the respective launch time.

Let’s go a little technical here.

1. Track your launch time
2. Find gray areas
3. The solution to gray areas
4. Helping tools

Track your launch time: Talking about android you can track your launch time using the android studio Logcat console, firebase console under the performance tab. Compare it with the threshold time mentioned above

Find gray areas: This threshold comparison will help you identify those areas that required your attention and action

The solution to grey areas: Key areas are usually entry points of your application, for example in android OnCreate methods of application/activity/fragment is the one that usually creates this mess. So to avoid these launch issues try using a lazy loading approach instead of going with greedy intialization. Load your heavy assets in a manner that they don't interrupt your launch point time.

Conclusion

Launch time performance is one of those topics which are less likely discussed in your software performance meetings, but this is one of the most important aspects of your app. Your app’s launch time is the first impression you leave on your user, and you would never want your user to leave you just like 60%+ users do when they find a slow starter app :).

I hope you liked this effort to bring this topic to light. if you liked it please share it, clap, and subscribe if you want to have more topics like this.

Bye-bye.

Reading materials

https://developer.android.com/topic/performance/vitals/launch-time

Measure Android app startup time

How to correctly measure the App Startup time on Android