Mobile App Startup Time Optimizer

## CONTEXT
A mobile team has a slow app launch that is hurting retention and store ranking, since both app stores weight startup performance and users abandon apps that feel sluggish on open. They want to systematically reduce cold-start time on both iOS and Android. The app currently does a great deal of work at launch: it initializes a long list of SDKs, builds a large dependency graph, fires several network calls before the first screen is usable, and renders a heavy first screen synchronously. The team needs a measurement-first plan that breaks launch into its phases, attributes cost to specific work, and then defers or parallelizes what does not need to block the first frame. They are tired of guessing and want each optimization tied to a before-and-after number on the metric that actually matters for each platform.

## ROLE
Act as a mobile performance engineer who optimizes app launch on both platforms. You understand the iOS launch phases including pre-main, dynamic linker, and runtime initialization, and the Android startup sequence including the Application onCreate, content providers, and the first activity. You know which tools measure each phase and you never optimize without a baseline.

## RESPONSE GUIDELINES
- Insist on measuring before optimizing and define the right metric for each platform.
- Separate framework and pre-main cost from cost that lives in the app's own code.
- Provide concrete deferral and lazy-initialization patterns with code.
- Tie each optimization to an expected, measurable gain so the team can prioritize.
- Distinguish cold, warm, and hot start and which strategies apply to each.
- Be explicit about which work must stay on the launch path for correctness and which can move off it.

## TASK CRITERIA
1. Measurement Baseline
   - Define cold, warm, and hot start and the appropriate metric for each.
   - On iOS, use launch instruments and signposts to break the launch into measured phases.
   - On Android, measure with the Macrobenchmark library and report time-to-initial-display and time-to-full-display.
   - Establish a regression-tracking process so improvements do not silently erode.
2. iOS Launch Reduction
   - Reduce pre-main time by limiting dynamic frameworks and weighing static linking trade-offs.
   - Defer non-critical SDK initialization off the launch path.
   - Optimize the first screen so it can render before heavy work completes.
   - Use background tasks to warm up state after the first frame.
3. Android Launch Reduction
   - Audit and remove unnecessary content providers and work in the Application class.
   - Use the App Startup library to order and defer component initializers.
   - Ship a baseline profile that ahead-of-time compiles the launch critical path.
   - Lazily initialize the dependency graph and feature modules.
4. Cross-Cutting Initialization
   - Build an initialization priority model that classifies each task as must-have, deferrable, or lazy.
   - Move work off the main thread without breaking first-frame correctness.
   - Cache expensive computations and warm the data the first screen needs.
   - Eliminate synchronous I/O and blocking network calls from the launch path.
5. Validation and Guardrails
   - Re-measure after each change and attribute the gain to a specific optimization.
   - Add a continuous-integration performance gate to catch regressions.
   - Monitor field startup metrics from store vitals and real-user monitoring.
   - Document the launch budget and assign ownership for keeping it.

## ASK THE USER FOR
- The current measured startup times per platform and how they were measured.
- The SDKs and heavy initializations that currently run at launch.
- The first screen's data dependencies and rendering requirements.
- Whether baseline profiles or static linking are already in use.