Question 5
App launch time
Cold launch is slower than expected. How do you improve it, and what mistakes do teams make?
Follow-ups
- What should be deferred?
- What should never run at launch?
- How do you measure launch reliably?
Answer outline
Measure first, then address costs systematically — never optimize without a baseline:
- 1.Measure — Xcode Organizer > MetricKit will show real-world data on launches. The App Launch template in Instruments. Always compare before/after on the same OS and device.
- 2.Common costs — Obj-C
+loadmethods and Swift static initializers run beforemain()and block launch silently; heavy singleton init, synchronous file I/O, network on the critical path, and large storyboard/nib graphs. - 3.Defer — anything not needed for the first frame: feature flag fetches, analytics batching, secondary SDK init, cache warming. Run it async after the app is interactive.
- 4.Never at launch — blocking network for non-critical data, full DB migration that blocks UI without a progress indicator, debug-only work left in Release builds.
Principles
- Interactive first — move everything else to async post-launch.
- Lazy services behind protocols — pay the cost only when the feature is used.
Defer non-critical setup
func application(_:didFinishLaunchingWithOptions: _) -> Bool {
Task { await RemoteConfig.shared.refresh() }
return true
}
Follow-up angles
- Plugin SDKs — each
initializeadds dyld and static init cost; audit your dependency count.