Cold Start / Warm Start / Hot Start

The three types of launch

The state of device memory at the moment of launch determines how long it takes the user to reach
their first interaction with content.

Cold start

The app process does not exist and the system creates it from scratch:

1. The OS allocates memory and creates the process
2. The runtime loads — the JVM or Dalvik on Android, the iOS runtime on Apple devices
3. The Application class or AppDelegate is initialised
4. The first screen is created (Activity or ViewController)
5. Data for the first screen is loaded

This is the most expensive scenario. Typical time is 500 milliseconds to three seconds, and in bad
cases eight to ten seconds.

Warm start

The process exists in memory, but the Activity or ViewController has been destroyed — the user
pressed back, or the OS reclaimed resources. There is no need to initialise the Application object;
only the UI has to be recreated.

Two to four times faster than a cold start.

Hot start

The app returns from the background: the process is alive and the context preserved. The OS resumes
the Activity or ViewController. For the user it is an instant return to the previous screen.

Why cold start matters in e-commerce

In e-commerce apps cold start matters most in two scenarios.

Arriving from a push notification — the user has not opened the app for hours and it has been
evicted from memory. A cold start of three seconds or more cools the intent the push created. This
is the most expensive moment at which to lose a conversion.

The morning launch — the user opens the app first thing in the morning. If the first screen
loads slowly, the session starts in disappointment.

Important: track cold start in the Google Play Console (Android Vitals, app start-up time)
and in Xcode Instruments or MetricKit on iOS. Both let you see percentiles — p50 and p95 — not
just the average.

What slows a cold start down

• Synchronous network calls in Application.onCreate() — they block the main thread
• Heavy SDKs with eager initialisation — analytics, recommendations and push services
  initialising one after another
• Large DEX size — class loading takes longer
• Waiting for a server response before showing UI — the user sees a white screen instead of a
  skeleton

Optimisation recommendations

• Use the Splash Screen API (Android 12 and later) for a unified, optimised transition
• Initialise SDKs lazily — only those needed on the first screen go up front, the rest after
  content is displayed
• Show a skeleton screen immediately and load data asynchronously
• Use baseline profiles on Android to pre-compile hot code paths