Diagnose and fix slow iOS app launch time

WHAT THIS TESTS This assesses whether you understand the full launch pipeline, including the pre-main work the system does before your code runs, and whether you optimize by measurement rather than guesswork. It is a strong signal of low-level platform competence.

A GOOD ANSWER COVERS Launch splits into pre-main and main. Pre-main is owned by dyld: loading the executable and its dynamic libraries, rebasing and binding pointers for ASLR and symbol resolution, running Objective-C class registration and +load methods, and executing C++ static initializers and any global constructors. Main begins at your entry point and spans application(_:didFinishLaunchingWithOptions:), scene connection, and rendering the first frame, after which launch is considered complete. To diagnose, use the App Launch template in Instruments to see the time split across phases, watch for excessive dynamic library count, and check signposts for the first-frame moment. Optimizations: reduce the number of dynamic frameworks or merge them, since each adds linking cost; eliminate +load and static initializers in favor of lazy initialization; defer analytics, database migrations, and feature setup off the critical path; avoid synchronous I/O and heavy work in didFinishLaunching; and lazy-load the first screen's data.

COMMON WRONG ANSWERS Profiling only your application code and missing the pre-main cost of too many dynamic libraries. Changing code without measuring first. Believing all initialization must happen in didFinishLaunching.

LIKELY FOLLOW-UPS Why do many dynamic libraries hurt launch? What is the difference between static and dynamic linking here? Where do +load and initialize differ? How do you measure the first-frame time?

ONE CONCRETE EXAMPLE An app links thirty separate dynamic frameworks and runs database migrations synchronously in didFinishLaunching. Instruments shows half the launch time is pre-main dyld work and the rest is the blocking migration. Merging frameworks into fewer modules cuts pre-main time, and moving migration to a background task after the first frame lets the UI appear immediately, dramatically reducing perceived launch time.