App startup time is the interval between the user’s launch action, such as tapping an icon, and the moment the app displays its first frame and becomes usable. In mobile performance, it is one of the most visible quality metrics, because every session begins with it and users judge an app’s speed largely by how fast it opens.
Startup time is not a single number. Platforms distinguish cold, warm and hot starts depending on how much of the app is still in memory, and they separate the time to the first frame from the time until real content is shown.
Cold, warm and hot starts
The type of start depends on the state of the app process when the user launches it. A cold start is the slowest and most important case, because it includes every step from creating the process to drawing the first screen.
| Start type | Starting state | Work required |
|---|---|---|
| Cold start | No process exists | Create process, load code, initialize app, build and draw first screen |
| Warm start | Process exists, screen destroyed | Recreate the screen and restore saved state |
| Hot start | Process and screen in memory | Bring the existing screen to the foreground |
Cold starts happen after a reboot, after an update, and whenever the operating system has reclaimed memory by killing the app in the background. On low-memory devices this happens often, so cold start performance affects real users far more than tests on a developer’s phone suggest.
What happens during a cold start
A cold start is a chain of steps, and every step on the main thread delays the first frame. Understanding the chain shows where time is spent and which parts the developer controls.
- The system creates the process and maps the app binary and libraries into memory.
- The runtime loads code; on iOS the dynamic linker binds frameworks, and on Android the runtime loads compiled code.
- The application object initializes, including every library and dependency set up at launch.
- The first screen is created, its layout is inflated or composed, and data is read.
- The first frame is measured, drawn and handed to the display.
Developers typically control steps three and four, which are also where the largest delays hide. Common culprits are synchronous disk or network access, heavy dependency injection graphs, analytics and advertising SDKs initialized eagerly, and complex first-screen layouts.
How app startup time is measured
Each platform defines standard startup metrics so that results are comparable across devices and builds. The table lists the most widely used ones.
| Metric | Platform | Definition |
|---|---|---|
| Time to initial display (TTID) | Android | Launch until the first frame is drawn |
| Time to full display (TTFD) | Android | Launch until the app reports content is ready |
| Time to first frame | iOS | Launch until the first frame renders |
| Launch time histogram | iOS | Field distribution of launch times across users |
| Startup vitals | Android | Share of sessions with excessively slow starts |
Measurements in the lab should run on release builds on mid-range or low-end devices, repeated many times, with results reported as a median and a high percentile such as p90. Debug builds and single runs give misleading numbers.
As practical reference points, Android treats a cold start of 5 seconds or more as excessive in its vitals reporting, and Apple recommends drawing the first frame within roughly 400 milliseconds. Well-optimized apps usually reach a cold start of about one second or less on typical devices.
Techniques that reduce app startup time
The most effective optimization is doing less work before the first frame. Anything that is not needed to show the first screen should be deferred, made lazy or moved off the main thread.
| Technique | How it helps | Platform |
|---|---|---|
| Lazy initialization | Starts SDKs only when first used | Both |
| Background threads for I/O | Keeps the main thread free | Both |
| Baseline Profiles | Precompiles startup code paths | Android |
| Fewer dynamic frameworks | Reduces dynamic linking time | iOS |
| Simpler first screen | Less layout and rendering work | Both |
| Cached content | Shows stored data while fresh data loads | Both |
A splash screen does not make an app faster. It covers the time to the first frame with a branded image, but the real wait until usable content appears stays the same unless the underlying work is reduced.
Startup time compared with related performance issues
Startup time is closely linked to other mobile performance metrics. Very slow startup can escalate into an ANR or a watchdog termination when the main thread is blocked long enough for the system to intervene.
| Metric | What it measures | Relation to startup |
|---|---|---|
| ANR | Main thread unresponsive for several seconds | Severe startup blocking can trigger it |
| Crash rate | Unexpected terminations | Startup crashes block the whole app |
| Frame rendering time | Smoothness after launch | Shares the same main-thread causes |
| Battery usage | Energy per session | Heavy launch work also drains power |
Stripped to the essentials
App startup time is how long you wait after tapping an app before you can use it. A fast app opens almost instantly. A slow one makes you stare at a logo.
Opening an app from scratch is like opening a shop in the morning. The lights, the till and the shelves all need preparing. A well-run shop opens the door first and finishes the rest while customers browse. Good apps work the same way.
Where it is applied
A grocery delivery app shows a median cold start of 3.8 seconds on mid-range Android phones, and store reviews mention the slow launch. Profiling a release build reveals that the app initializes six third-party SDKs, reads a large configuration file and loads the full product catalog before drawing the home screen.
The team defers four SDKs until after the first frame, moves file reading to a background thread, shows cached products from the last session and adds a Baseline Profile. The median cold start falls to about 1.2 seconds, the share of slow starts reported in vitals drops sharply, and the checkout conversion rate improves in the following release cycle.