6.4 · The launch path: dyld, initialisers and the first frame
The first impression of an app is the time between the tap and the first frame. Most of that time is spent before your first line of Swift, so staff-level questions ask what the system does and what you control.
Mental model. Launch has two halves: before main (the system loads and links your binary) and after it (your code builds the first screen). You only fully own the second half, but you decide how much work the first half has to do.
The path
From tap to first frame, and what runs when.
- Walk through what happens from tapping the icon to the first frame.
The system asks the process supervisor to start your app. The kernel executes the binary and hands control to dyld, the dynamic linker, which maps the main… - What does dyld do, and how do static and dynamic linking change launch?
dyld is the dynamic linker. It reads the binary’s load commands, maps each dependent dylib (your own frameworks plus system libraries), then performs rebase…
The cost
What makes launch slow, and how to measure and cut it.
- Your app launches slowly. How do you find out why and what do you cut?
Measure first, on a real device, in a Release configuration. Instruments’ App Launch template splits the timeline into system work, dyld, static initialisers…
More in iOS platform internals
- 6.1 · The process, the sandbox, entitlements and privacy prompts
- 6.2 · App and scene lifecycle in UIKit and SwiftUI
- 6.3 · The run loop, its modes, and the main-thread contract
- 6.5 · Background modes, BGTaskScheduler and background transfers
- 6.6 · Memory warnings, jetsam and the watchdog
- 6.7 · Info.plist, URL schemes, universal links and associated domains
- 6.8 · App groups, keychain groups and extensions as separate processes
- 6.9 · How a process dies, what it costs, what confines it and what seals it
- 6.10 · Threads and run loops, observers, and what actually runs in a custom mode
- 6.11 · Launch arguments, the scene callbacks, and reading a binary and its plists