How do you optimize app launch time?

1. Understand the phases first — you can’t optimize what you haven’t measured in stages

• Pre-main time — dyld loading the binary and linked dynamic libraries, +load methods, static initializers. Measurable via DYLD_PRINT_STATISTICS or Instruments’ App Launch template.
• main() to first frame — your app’s launch delegate work, initial view controller setup, up to first rendered frame.
• First frame to interactive — the gap between something appearing and the app being usable.

2. Reduce pre-main time — dynamic library and initializer discipline

• Minimize embedded dynamic frameworks/libraries — dynamic linking overhead scales with library count.
• Avoid unnecessary +load methods and heavy static initializers — prefer lazy initialization.
• Audit third-party SDKs for deferred/lazy initialization options.

3. Defer non-critical work past the first frame

func applicationDidFinishLaunching() {
    setupCriticalDependencies()   // only what the first screen actually needs
    showInitialUI()
    Task {
        await setupNonCriticalServices()  // analytics init, remote config, cache warming
    }
}

4. Avoid synchronous network/disk I/O on the launch path

Show the UI first (with cached/placeholder data if needed), then load real data asynchronously once the first frame is up.

5. Lazy dependency graph construction

A composition root that eagerly constructs the entire app’s dependency graph at launch pays a real cost proportional to app size, most of which is wasted since the user is only looking at one screen. Constructing only what the first screen needs, and lazily constructing the rest on first navigation, is a direct, measurable launch-time win — one of the problems that appears specifically at scale.

6. Modularization’s indirect launch-time benefit

Heavier modularization primarily helps build time, but it also indirectly supports launch-time discipline by making it structurally harder for a feature module’s setup code to run eagerly at launch when it isn’t the first screen.

7. Reduce work in viewDidLoad/initial view setup specifically

Time Profiler traces of slow launches often point to the first view controller doing more than necessary — synchronous image decoding, expensive layout, JSON parsing of bundled data. Move decoding off the main thread, defer non-visible content, cache/precompute.

8. Reduce asset/bundle overhead

• Large, unoptimized image assets add real, measurable time — compress and size appropriately (same downsampling discipline as image caching).
• On-demand resources for content not needed at launch.

9. Measure continuously — this is a regression-prone metric

• MetricKit’s MXAppLaunchMetric for real-world production data.
• XCTest performance tests (XCTClockMetric) with CI-tracked baselines.
• os_signpost markers around specific launch stages so a regression shows up as “this stage got slower,” not just “launch got slower.”

10. Instruments — the diagnostic tool for a specific slow-launch investigation

The App Launch Instruments template specifically breaks down pre-main vs. post-main time and highlights the biggest individual contributors.

Interview-ready summary

Phase	Lever
Pre-main (dyld)	Fewer dynamic frameworks, avoid +load/eager static initializers
Launch → first frame	Defer non-critical service setup, lazy dependency graph construction
First frame → interactive	Avoid synchronous network/disk I/O on the launch path, defer non-visible content
View setup	Move decoding/heavy computation off main thread, cache/precompute
Assets	Compress/size appropriately, on-demand resources for non-critical content
Regression prevention	MetricKit (production), XCTest performance baselines (CI), os_signpost (stage-level)
Diagnosis	Instruments’ App Launch template for pre-main vs. post-main breakdown

One-liner if pressed: “I’d start by measuring the actual phases — pre-main dyld/initializer time versus post-main setup versus time-to-interactive — using Instruments’ App Launch template, since the fix differs by phase: reducing dynamic framework count and eager static initializers for pre-main, deferring everything not required for the first screen and constructing the dependency graph lazily for post-main, and moving any synchronous I/O or heavy view setup off the critical path — then locking in the gains with MetricKit for real-world production data and XCTest performance baselines in CI so a regression is caught at the PR that introduced it.”