How We Reduced iOS App Launch Time by Up to 99% on Low-End Devices

1. Introduction

Through instrumentation we discovered that some users experience launch times of around 10‑20 seconds, especially on low‑end devices such as iPhone 6, iPhone 7, iPhone 8. Imagine being late for a date and the app takes dozens of seconds to start – how can we improve this?

2. Optimization Effect

Statistical analysis of launch‑time data shows it is necessary to optimize launch, particularly on low‑version devices with limited memory, to improve user experience and retention.

Before optimization:

After optimization:

In version 1.4.0 the distribution is:

Less than 3 s: 99.7 %

3 s‑4 s: 0.13 %

4 s‑5 s: 0.04 %

Greater than 5 s: 0.006 %

Based on these results we summarize the optimization from three aspects:

Identify methods that cause long launch time.

Analyze why they are slow.

Apply optimizations to reduce launch time.

For detailed guidance see the previous article “HuoLala User‑Side Experience Optimization – Launch Optimization”.

3. Detailed Optimization Process

The work is divided into three phases.

Phase 1: Optimize long‑running functions and handle low‑version devices specially.

Phase 2: Optimize the entire business flow during launch.

Phase 3: Optimize passive‑launch scenarios.

Phase 1: Long‑Running Functions and Low‑Version Devices

In the first phase we used Instrument, App Launch Time Profiler and other tools to measure function durations on low‑version devices (iPhone 6, iPhone 7) with memory < 100 MB. Functions taking more than 100 ms were listed.

launchView: 150‑250 ms

Analytics SDK initialization: 300‑650 ms

Map SDK initialization: 250‑500 ms

toastView initialization: 100‑260 ms

Home page AMap initialization: 600‑1200 ms

Home page background animation loading: 300‑600 ms

On newer devices (iPhone 11, iPhone 12) the same functions take considerably less time.

launchView: 50‑100 ms

Analytics init: 100‑200 ms

Map SDK: 50‑150 ms

toastView: 30‑80 ms

Home AMap: 200‑350 ms

Background animation: 80‑200 ms

launchView Optimization

launchView is only needed on first install for the privacy dialog. Its image is stored in the bundle instead of an Asset Catalog, so we compress the image losslessly and manage it via Asset Catalog, which reduces file size and loading time. The catalog also creates a .car file that can be memory‑mapped, offering a faster load path.

We also add a guard so launchView is created only on first install.

Effect: On low‑end devices launchView time reduced from 150‑250 ms to 80‑180 ms, a saving of about 60 ms.

Analytics SDK Initialization Optimization

The analytics SDK fetches the Wi‑Fi BSSID and creates a WKWebView to obtain the user‑agent. The Wi‑Fi fetch is only needed on Wi‑Fi networks, so we add a network‑type check before calling it. We also replace AFNetworkReachabilityManager with Alamofire’s NetworkReachabilityManager to obtain the network status earlier.

We cache the user‑agent on disk because it depends only on OS version and device model.

Effect: Wi‑Fi BSSID fetch time becomes negligible on mobile networks; WKWebView user‑agent fetch time reduced by about 200 ms.

Map SDK Initialization Optimization

Map SDK initialization includes location reporting and IQKeyboardManager configuration, both of which are heavy on low‑end devices. We delay these initializations until viewDidAppear on low‑end devices, keeping them immediate on newer devices.

Effect: Map SDK init time reduced by 80‑200 ms on low‑end devices.

toastView Optimization

toastView is a third‑party UI component used only after the user navigates to payment or IM screens. We delay its creation on low‑end devices until after launch is complete.

Effect: toastView init time reduced by 100‑260 ms.

Home Page AMap Initialization

AMapView creation takes ~800 ms on low‑end devices versus ~200 ms on newer devices. We delay its creation until after launch statistics are collected on low‑end devices.

Effect: Overall launch time reduced by about 600 ms.

Home Page Background Animation Optimization

The animation originally used 140 images loaded synchronously on the main thread. We reduced the number of images, show a placeholder first, and load the rest asynchronously.

Effect: Animation loading time reduced by ~300 ms.

Other Optimizations

We moved HDID initialization, ASA advertising initialization, and security SDK initialization to an asynchronous serial queue. These tasks are lightweight but were causing occasional crashes when run in background threads, so we kept them on the main thread.

Launch Manager

The launch manager handles three responsibilities:

Determine whether the device is a low‑version model by parsing the device identifier and comparing the major version to a threshold (default 11).

Provide APIs to add tasks to the main queue or an asynchronous queue.

Support delayed execution of tasks on low‑end devices after the run‑loop becomes idle.

Implementation details include device‑model detection using uname, building a task list with priority, sorting, and executing delayed tasks via a CFRunLoop observer that triggers when the run‑loop is about to sleep.

private class func isLowerPhoneDevice(_ lowPhoneVersionLimit: Int) -> Bool {
    // implementation omitted for brevity
}

Phase 2: Business‑Flow Optimization

We optimized unused classes, removed default‑instantiated optional components, added state checks for login‑dependent flows, and reduced package size by converting dynamic third‑party frameworks to static, deleting unused libraries, and compressing assets with Asset Catalog.

Effect: Package‑size‑related launch overhead reduced by 60‑150 ms.

Phase 3: Passive‑Launch Optimization

Background fetch, location updates, and silent push notifications can wake the app while it is in the background, counting as a “passive launch”. This accounts for ~30 % of launch events and can be slower because the app runs at a lower priority.

We removed unnecessary Background Modes (e.g., Background Fetch) and added a check of applicationState to filter out passive‑launch statistics from reporting.

Effect: After filtering passive‑launch data, the proportion of launches under 3 s rose to 99.7 %.

4. Summary

Key take‑aways:

Identify the slowest functions first, review code, and apply targeted fixes.

Test under worst‑case conditions (low‑end devices, low memory) to obtain realistic metrics.

Maintain a downgrade plan to revert optimizations if regressions appear.

Implement anti‑regression measures: code review, library audit, automated performance testing on a device farm, and daily monitoring with alerts.