Optimizing Mobile App Launch Time (Warm Start)

In our practice, we often see apps that work perfectly on cold start but lag when returning from background — on mid-range Android devices, the delay reaches 2–3 seconds. Warm start occurs when the app process is alive but the Activity/ViewController is recreated: after swiping from Recent Apps, the system restores the Activity via SavedInstanceState, on iOS when returning from background after the ViewController was unloaded due to memory pressure. Developers often overlook that during warm start, onCreate (Android) or viewDidLoad (iOS) is called again, and all initializations run anew.

Warm start is faster than cold start (JVM/VM already running, Application code executed), but slower than hot start, where the screen is simply restored from the stack. The problem is that state restoration during warm start is often done incorrectly: saving large objects in Bundle, synchronous database queries, recreating HTTP clients. We guarantee a warm start speedup of at least 50% through proper architecture — ViewModel with SavedStateHandle, data caching, and a singleton provider for network services.

How to Avoid SavedInstanceState Problems on Android?

The main pitfall of warm start on Android is improper handling of SavedInstanceState. When the Activity is destroyed, the system calls onSaveInstanceState, the developer saves data, and the Activity is recreated with savedInstanceState != null. All is fine — until large objects end up in the Bundle. Bundle is not designed for serializing large data — 500KB Bitmap images or a serialized list of 200 objects cause TransactionTooLargeException or a silent crash. Rule: only IDs and minimal state in Bundle, data in ViewModel, which survives Activity recreation.

ViewModel with SavedStateHandle is the correct approach: SavedStateHandle stores only IDs/primitive values in Bundle, full data is kept in ViewModel.stateFlow and restored from the repository by ID when needed. Our experience shows this reduces restoration time by 70%.

Heavy operations in onCreate during warm start is a classic mistake. Developers write code for cold start, forgetting that onCreate is called again on warm start. Initializing Room, creating Retrofit client, starting WorkManager — all this should not repeat on every onCreate. Dagger/Hilt @Singleton solves for infrastructure components, but the initialization logic must be monitored.

Why State Restoration on iOS Is a Weak Point?

On iOS, warm start occurs when returning to the app after the ViewController was unloaded due to didReceiveMemoryWarning. viewDidLoad is called again, as is viewWillAppear. The problem: if all screen initialization logic is in viewDidLoad, it will execute again — making extra network requests, recreating UI, losing scroll position.

UIKit State Restoration API (encodeRestorableState, decodeRestorableState) is the correct mechanism, but rarely used due to complexity. According to Apple State Restoration Programming Guide, using encodeRestorableState allows saving complex states, but many developers prefer manual approaches: saving state in UserDefaults or via Codable to a file.

SwiftUI handles this better through @StateObject and @AppStorage — state automatically survives View recreation. However, when using UIKit hosting (UIHostingController), care must be taken not to recreate @StateObject on each wrapping.

The main performance loss on iOS during warm start is repeated network requests for data already loaded before unloading. A proper caching layer in the repository (NSCache for in-memory, CoreData/Realm for persistence) allows immediately showing cached data and updating in the background. This reduces time to display by 60%.

Case Study: Accelerating Warm Start in E-Commerce from 1.8 to 0.4 Seconds

In our practice, we had a project — an online store with a product catalog. Warm start on mid-range Android took 1.8 seconds. Profiler showed: 900ms — recreating Retrofit/OkHttp clients in Fragment.onCreateView, 400ms — synchronous Room query to load categories, 500ms — inflating a complex RecyclerView layout.

What Tools to Use for Measurement?

Android: adb shell am start -W package/activity — shows TotalTime for warm start. For detailed analysis, use Perfetto with the ActivityThread.handleStartActivity section. Firebase Performance Monitoring automatically tracks startup traces in production.

iOS: Instruments → Time Profiler with the App Launch template. MetricKit in iOS 13+ collects MXAppLaunchMetric with breakdown into cold/warm/resume.

Launch Types: Cold, Warm, Hot

Table of Typical Problems and Solutions

Process and What's Included

1. Analytics — measure warm start time on target devices, profiling (Perfetto, Instruments).
2. Design — state restoration architecture, caching tools selection.
3. Implementation — refactoring initialization, adopting ViewModel/SavedStateHandle, cache layer.
4. Testing — on 5+ real devices, including older models.
5. Documentation — description of the new approach for maintenance.

Note: What's included in the work:

• Audit of current warm start time.
• Identifying bottlenecks: repeated initializations, heavy operations in onCreate/viewDidLoad.
• Refactoring: implementing ViewModel, singletons, caching.
• Testing on real devices.
• Guarantee of reducing warm start time by 50%.

We are a team with 8 years of experience in mobile development, having completed more than 20 performance optimization projects. Order a warm start audit for your app — we will profile and propose turnkey optimizations within two weeks. Contact us for a project evaluation.