Hot Start in Mobile Apps: What It Is, Factors and How to Speed Up

What Is Hot Start in Mobile Apps

Hot Start is a launch scenario where the app’s process already exists in the device’s RAM. The user minimizes the app, then returns — and the system does not create a new process but resumes the existing one. In this scenario, no OS loading, Application class initialization, or process creation is required, which dramatically reduces the time until the UI appears on screen. According to Android Documentation (2025), Hot Start takes only 200–500 ms, while Cold Start can reach 5 seconds or more. The speed difference is especially noticeable on devices with limited memory, where the system more frequently unloads background apps.

The main feature of Hot Start is the minimal set of lifecycle methods called. In Android, these are Activity.onCreate and Activity.onStart; in iOS, it is applicationDidBecomeActive. Unlike Cold Start, where Application.onCreate, ContentProvider.onCreate, Activity.onCreate, and many library initializations are called sequentially, Hot Start skips all these stages. The developer must understand which code runs specifically during a hot start — often heavy SDK initializations, analytics, and DI containers are repeated on both Cold and Hot Start, even though they are no longer needed during a hot start.

Cold Start, Warm Start and Hot Start: Comparison

The three app launch scenarios differ in initialization depth. Cold Start occurs when the app is launched for the first time after installation, device reboot, or being evicted from memory. The system creates a new Linux process, loads Application classes, creates ContentProvider instances, performs library initialization, and only then renders the Activity. The entire process takes 2–10 seconds depending on app complexity and device characteristics.

Warm Start is an intermediate scenario. The app process is alive in memory, but the Activity was destroyed and must be recreated. This happens, for example, on screen rotation or when returning from another app where the Activity was evicted due to memory pressure but the process remained. Warm Start includes calling Activity.onCreate and Activity.onStart, but does not include Application.onCreate or ContentProvider initialization. Warm Start time is 500 ms to 2 seconds. Hot Start is the fastest of the three: the Activity already exists in the back stack, the process is alive, and the system simply calls Activity.onRestart, onStart, and onResume. Hot Start time is 200–500 ms. The difference from Warm Start is that the Activity is not created anew — it is restored from the existing instance.

Android Lifecycle During Hot Start

In Android, Hot Start is triggered when the user returns to the app via the Recents screen or by tapping the app icon while it is minimized. The system checks whether the process is alive, and if so, calls Activity.onRestart, onStart, and onResume sequentially. The onCreate method is not called during Hot Start because the Activity instance already exists in memory. This is an important difference from Warm Start, where onCreate is still called due to Activity destruction. According to Google I/O 2019, typical Hot Start time in Android is 200–400 ms, and any slowdown at this stage directly increases perceived launch time.

Developers often overlook that UI initialization code, LiveData subscriptions, or RecyclerView setup are performed not only in onCreate but also in onStart or onResume. During Hot Start, these code blocks execute again, even though the UI was already configured. It is recommended to separate one-time initialization (in onCreate with a savedInstanceState check) and resumable logic (onStart/onResume). For example, heavy operations — adapter setup, list loading — should be moved to a block that does not execute during onRestart, or check savedInstanceState.

Example of tracking launch type

The following Kotlin code demonstrates a simple way to detect the start scenario and measure time. The launchTimeStamp variable captures the launch start moment, and isColdStart allows separating logic for cold and hot start.

class MainActivity : AppCompatActivity() {

    private var launchTimeStamp = 0L
    private var isColdStart = true

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        if (savedInstanceState == null) {
            isColdStart = true
            launchTimeStamp = System.currentTimeMillis()
            // one-time initialization
        } else {
            isColdStart = false
            // Hot Start — Activity is restored
        }
    }

    override fun onResume() {
        super.onResume()
        if (isColdStart) {
            val launchTime =
                System.currentTimeMillis() - launchTimeStamp
            Log.d("LaunchTime", "Cold Start: $launchTime ms")
        }
    }
}

iOS Lifecycle During Hot Launch

In iOS, Hot Start corresponds to returning the app from the background via sceneDidBecomeActive (UIKit) or onAppear (SwiftUI). The operating system does not recreate the process if the app was in a Suspended or Background state. During a hot launch, applicationDidBecomeActive is called in AppDelegate, but applicationDidFinishLaunching is not called — this is analogous to Android where Application.onCreate is skipped. iOS more aggressively evicts apps from memory: if the device lacks RAM, the system may evict a background app, and the next launch will be a Cold Start. According to Apple Developer Documentation, the average Hot Start time in iOS is 300–600 ms.

A key difference in iOS is the lack of a direct Warm Start analog in the Android sense. In iOS, when an app is minimized, sceneDidEnterBackground is called, and upon return, sceneWillEnterForeground and sceneDidBecomeActive are called. If the system evicts the scene but keeps the process alive, the next launch will be Cold from the scene perspective but Hot from the process perspective. The developer must consider this when placing initialization code: subscriptions to NotificationCenter, UI updates, and state resets should be in sceneDidBecomeActive, not only in viewDidLoad.

Example of handling Hot Start in iOS

This Swift code shows how to track the number of hot launches and separate logic. The foregroundCount counter increments on each return from the background.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

    func sceneDidBecomeActive(
        _ scene: UIScene
    ) {
        foregroundCount += 1

        if foregroundCount == 1 {
            // Cold Start — full initialization
            setupSDKs()
        } else {
            // Hot Start — UI update only
            refreshUI()
        }
    }

    private func refreshUI() {
        // updating data on screen
    }
}

Factors Affecting Hot Start Speed

Several categories of factors affect Hot Start speed. The first is the amount of work in the onStart and onResume lifecycle methods. If the developer placed network data loading, JSON parsing, adapter initialization, or heavy computations in these methods, each such block adds tens or hundreds of milliseconds to startup time. According to Android Vitals, apps with Hot Start duration exceeding 800 ms lose up to 20% of users upon return.

The second category is fragments and Views restored from savedInstanceState. If fragments contain heavy ViewPager2, WebView, or complex deeply nested hierarchies, their restoration consumes CPU resources. According to Google I/O 2023, each nested ViewGroup adds an average of 2–5 ms to rendering time during Hot Start. The third category is third-party SDKs: analytics libraries, crash-reporting tools, A/B testing frameworks, and DEX loaders may perform initialization on every return from background. It is recommended to check which SDKs run code specifically in onStart/onResume and defer non-critical tasks to a background thread.

Hot Launch Optimization Methods

Hot Start optimization boils down to minimizing work in the resumption lifecycle methods. The first method is lazy initialization: any code not needed for the first UI frame should run after onResume with a delay via Handler.postDelayed or Coroutine.launch(Dispatchers.IO). The second method is View state caching: when the app is minimized, save data to an in-memory cache so that during Hot Start you do not reload it from the database or network. The third method is using SavedStateHandle in Android and StateRestorationPolicy in iOS to minimize the amount of restored data.

Lazy loading after Hot Start

In this example, Handler.postDelayed defers analytics initialization by 500 ms after the first frame is rendered. This does not affect perceived launch time because the user already sees the interface.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // initialization after the first frame
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

Using the App Startup library

AndroidX App Startup allows you to control the initialization order of components at launch. All ContentProviders are initialized automatically during Cold Start, but you can disable automatic initialization for components not needed during Hot Start.

@Initializer(Application::class)
class SdkInitializer : Initializer<Unit> {

    override fun create(context: Context) {
        SdkOne.init(context)
        SdkTwo.init(context)
    }

    override fun dependencies() = emptyList<Class<*>>()
}

Launch Time Monitoring Tools

For measuring Hot Start time, both built-in platform tools and third-party solutions exist. In Android, the key tool is Android Vitals in Google Play Console — it automatically collects launch time metrics for all scenarios (Cold, Warm, Hot) broken down by device model and OS version. Additionally, you can use Macrobenchmark from AndroidX — a library for automated startup performance testing. In iOS, the equivalent is MetricKit, which collects data on launch time, frame rate, and memory usage.

For detailed hot start profiling, Firebase Performance Monitoring (tracks custom traces) and New Relic with launch time dashboards are suitable. On the developer side for manual measurement, reportFullyDrawn in Android is used — an API that tells the system the exact moment when the UI is rendered and ready for interaction. In iOS, the equivalent is endActivity in MetricKit. By combining these tools, you can identify which SDK or code block slows down Hot Start on specific devices.

Macrobenchmark example for Hot Start

Kotlin code using the Macrobenchmark library to measure Cold and Hot Start. The test launches the Activity and measures the time until the complete state.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {

    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun hotStart() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 10,
            startupMode = StartupMode.HOT
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}