iOS App Launch Process, Optimization Strategies, and Binary Reordering Techniques

The article begins by describing the iOS app launch sequence, which starts when the user taps the app and ends after AppDelegate 's didFinishLaunching method completes. Launches are divided into cold starts (process not yet in memory) and hot starts (process already resident after a previous launch).

Launch‑time optimization mainly targets the cold‑start phase, which is split into two parts: work performed before the main function and work performed after it. Before main , the OS loads the executable, performs dynamic library loading, rebasing, symbol binding, class registration, and executes load and constructor methods. The article lists each step, its typical time cost, and practical suggestions such as reducing the number of dynamic libraries, merging them, removing unused classes, and minimizing load usage.

After main , the focus shifts to initializing third‑party SDKs, custom utilities, loading first‑screen data, and performing first‑screen rendering calculations. Recommendations include limiting work to first‑screen tasks, deferring non‑essential initialization to background threads, removing dead code, and avoiding XIB/Storyboard in favor of pure code for the launch UI.

The next section introduces binary reordering. It first explains physical memory, virtual memory, paging, and the ASLR security mechanism, then shows how iOS loads pages on demand, causing page‑faults that increase launch time. Binary reordering aims to place all methods used during launch at the beginning of the binary, reducing page‑faults.

To implement binary reordering, the article describes creating an order file for the linker ( ld ) and configuring it in Xcode's Build Settings. Several ways to generate the order file are presented: manual selection, hooking objc_msgSend , static scanning of Mach‑O sections, and Clang instrumentation using SanitizerCoverage .

For Clang instrumentation, the steps are:

Enable SanitizerCoverage in the project (add -fsanitize-coverage=func,trace-pc-guard for Objective‑C or -sanitize-coverage=func and -sanitize=undefined for Swift).

Insert hook functions that record each function's address when __sanitizer_cov_trace_pc_guard is called.

Use dladdr to resolve addresses to symbol names.

Store symbols in a thread‑safe queue, deduplicate them, and write them to an order file after the first screen finishes loading.

Example instrumentation code (kept unchanged):

void __sanitizer_cov_trace_pc_guard_init(uint32_t *start, uint32_t *stop) {
        static uint64_t N;  // Counter for the guards.
        if (start == stop || *start) return;  // Initialize only once.
        printf("INIT: %p %p\n", start, stop);
        for (uint32_t *x = start; x < stop; x++)
            *x = ++N;  // Guards should start from 1.
    }

    void __sanitizer_cov_trace_pc_guard(uint32_t *guard) {
        if (!*guard) return;
        void *PC = __builtin_return_address(0);
        char PcDescr[1024];
        printf("guard: %p %x PC %s\n", guard, *guard, PcDescr);
    }

After collecting symbols, the article shows how to write them to a temporary *.order file, configure Xcode to use this file, and verify the effect by comparing link‑map outputs before and after reordering.

Overall, the guide provides a complete workflow—from understanding launch phases and memory concepts to applying linker order files and Clang coverage instrumentation—to reduce iOS app cold‑start latency.