How to Improve Mobile App Startup Time: Practical Wins for iOS & Flutter

iOS: Instruments

1. Open Xcode → Product → Profile → choose Time Profiler
2. Enable App Launch template to see pre-main vs post-main breakdown
3. Look for: heavy static initializers, synchronous network calls, large image decoding on main thread
4. Use os_signpost to add custom timing markers around your own initialization code
5. Check DYLD_PRINT_STATISTICS=1 environment variable for dylib load time breakdown

Flutter: DevTools

1. Run flutter run --profile — never optimize in debug mode
2. Open Flutter DevTools → Performance tab → enable "Track widget builds"
3. Use Timeline.startSync / Timeline.finishSync for custom markers
4. Check the App Size tool — large assets bloat startup
5. Run flutter build apk --analyze-size for a full binary size breakdown

Reduce Pre-Main Time (dylib loading)

• Merge small dynamic frameworks — each dylib adds ~2ms overhead. Aim for <6 non-system dylibs
• Use @_implementationOnly import for internal modules — removes them from the public interface and speeds linking
• Audit your SPM/CocoaPods dependencies — unused SDKs still load
• Use static libraries where possible — they're linked at compile time, not runtime
• Enable Dead Code Stripping in build settings — removes unreachable code

Optimize AppDelegate & SceneDelegate

• Move all non-essential init out of didFinishLaunchingWithOptions — Firebase, analytics, crash reporters can wait 1-2 seconds
• Use DispatchQueue.global().async for background-safe setup tasks
• Defer third-party SDK initialization until first use where the SDK supports it
• Remove synchronous network calls from startup — use cached data to render immediately

First Screen Rendering

• Show a skeleton/placeholder UI immediately — don't wait for network data to render anything
• Avoid layout on the main thread in viewDidLoad — pre-calculate layouts in background
• Use prefetchDataSource on collection/table views for off-screen cells
• Load images asynchronously — never decode images on the main thread
• Use SwiftUI's .task modifier instead of onAppear for async data loading — runs off main thread

Reduce Engine Initialization

• Use FlutterEngineGroup for multiple Flutter views — engines are expensive, share them
• Pre-warm the Flutter engine before navigation: FlutterEngine().run() in background
• Reduce main.dart top-level code — defer plugin registration to first use
• Use DeferredComponent for large features that aren't on the launch path

Widget Tree Optimization

• Keep the first-render widget tree shallow — defer complex subtrees with Visibility or lazy builders
• Use const constructors everywhere possible — prevents unnecessary rebuilds
• Replace Column / Row with ListView.builder for long lists — builds on demand
• Cache expensive build() results using RepaintBoundary

Release Build Flags

• Always measure in --release mode — debug builds are 10x slower
• Enable --split-debug-info to reduce binary size without losing crash symbolication
• Use --obfuscate with split debug info for production builds
• Enable tree shaking: unused icons and fonts are automatically removed in release builds

Asset Optimization

• Use WebP or AVIF for images — 30-50% smaller than PNG/JPEG with same quality
• Use vector assets (SVG/PDF) for icons — scale without quality loss, no @2x/@3x variants needed
• Remove unused assets — Xcode's asset catalog has a "Find Implicit Dependencies" option
• Compress launch screen images aggressively — they load synchronously on startup
• Use NSDataAsset for bundled JSON data instead of decoding at runtime

Network & Cache Strategy

• Show cached data immediately on startup — never block UI on a network response
• Use stale-while-revalidate: show cached content, refresh in background
• Prefetch critical data during the loading screen if you must show one
• Use HTTP/2 or HTTP/3 — multiplexing reduces latency for multiple simultaneous requests
• Cache API responses aggressively with proper TTLs — most startup data doesn't change per-session

Lazy Initialization Pattern

Apply this to any service that isn't needed on the critical path:

• Analytics SDKs — initialize on first event, not on launch
• Crash reporters — can initialize 2-3 seconds after launch (still catches 99%+ of crashes)
• Chat / support SDKs — initialize when user opens the help screen
• Payment SDKs — initialize when user reaches checkout
• Feature flags — load async, use defaults until loaded