How to Optimize iOS App Startup: Reduce Launch Time and Boost Retention

How to Define "Startup"

To analyze and solve startup problems we first need to define its scope: where it starts, where it ends, and the stages in between. Different perspectives lead to different conclusions.

Technical Perspective

From a developer’s view, startup is the program’s technical process. iOS startup is divided into cold start (no existing process) and hot start (process already in memory). The discussion focuses on cold start.

The iOS startup process can be split into two phases:

pre‑main: from process creation to entry of main(), covering environment preparation and resource loading.

post‑main: from main() to the end of -application:didFinishLaunchingWithOptions:, where we have code execution control and perform most optimizations.

<premain>                  <postmain>

+----------------X------------------------------------X-->

start          main                -didFinishLaunchWithOptions:

User Perspective

From the user’s side, startup is judged by the visual flow until the target page is rendered. It can be divided into three stages:

T1: Splash screen – a static view shown while the app is still in the pre‑main phase.

T2 (optional): Welcome/advertisement page – business‑driven, can be skipped.

T3: Target page – the home page or a specific landing page; its rendering marks the end of startup.

APM Methodology and Key Metrics

iOS startup governance is essentially an App Performance Management (APM) process, following four steps:

Define the problem : describe the phenomenon, set boundaries, and choose quantitative evaluation methods.

Analyze the problem : find root causes, assess importance and priority, and avoid treating symptoms only.

Solve the problem : design concrete technical solutions, quantify results with key indicators, and document findings.

Continuous monitoring : establish long‑term monitoring of critical technical indicators.

Key indicators :

Startup time : core metric affecting user experience and conversion. It can be broken down into technical (pre‑main, core‑post‑main) and subjective parts (T1_duration, T2_duration, T3_duration, total_duration).

Startup loss rate : measured as launch PV loss / first‑foreground PV or launch UV loss / DAU. A loss occurs when a user leaves the app before the target page is rendered.

Startup ad exposure rate : ad exposure PV / ad load PV; influenced by ad material size, caching, and exposure strategy.

Technical Optimizations

1. Optimize pre‑main

Key steps:

Reduce dynamic library usage: prefer static linking, merge libraries, and minimize rebase/rebind overhead.

Control the number of classes and selectors; avoid heavy +load methods.

Prefer Swift where possible, as it has no runtime, no initializers, and avoids data‑alignment issues.

Monitoring the start point can be done in Xcode with DYLD_PRINT_STATICS=1 or by injecting a custom ABootMonitor.dylib that records the earliest timestamp in its +load method.

2. Optimize post‑main

Focus on the two main callbacks:

-application:didFinishLaunchingWithOptions:

-applicationDidBecomeActive:

Recommendations:

Separate core startup items from non‑essential ones; execute only essential items in didFinishLaunching.

Run non‑essential items on background threads or delay them until the app becomes active.

Avoid heavy UI or network work in the launch callbacks to prevent CPU spikes and UI jank.

3. Fine‑grained Strategies

Interaction optimization : provide skip buttons on T2, add visual cues or animations on T1 to reduce perceived waiting time.

Scene‑based startup sessions : determine the launch scenario from parameters (first install, push entry, etc.) and create a tailored startup flow.

Ad caching and exposure strategy :

Separate ad material download from exposure; pre‑download during background fetch or idle periods.

Apply QoS levels: cache‑only for low priority, max‑wait for normal, max‑retry for high priority.

Expose ads on first foreground entry and on hot‑start returns to increase PV without harming user experience.

Platform Mechanisms

1. Memory Keep‑Alive

Increase hot‑start probability by releasing unnecessary resources when entering background, especially large images or caches, while preserving essential data.

2. Background Launch

Leverage iOS background mechanisms (Background‑fetch, silent push, geofencing, NSURLBackgroundSession, VOIP) to prepare resources or pre‑download ads. Ensure proper entitlements and user permissions, and be aware of power‑saving modes that may disable some mechanisms.

Structural Customization

Separate page‑stack creation, data fetching, and rendering:

Create the root page stack in didFinishLaunching.

Fetch data asynchronously just before the app becomes active.

Render the target page only when it is about to be displayed, possibly overlapping with T2.

Results

After three months of continuous optimization, the MaFengWo iOS app achieved:

Startup time reduced to ~3.6 s (≈50 % decrease).

PV startup loss rate lowered by ~30 %.

Startup ad exposure rate increased dramatically.

The work demonstrates that systematic startup governance, combined with performance monitoring and user‑centered interaction design, yields significant improvements in both technical metrics and user retention.

Future Work

The team plans to open‑source the startup framework soon and invites the community to follow the official WeChat account for updates.