LaunchLayer from source to store — the complete workflow
The full release lifecycle in one place, including what LaunchLayer automates, what happens in external services, and where human review is still required.
1. Start with the real input
Create a project from the material you actually control: a live HTTPS web app, GitHub repository, source ZIP, existing signed IPA/APK/AAB, or an existing store application. Source paths can support rebuild-oriented work; signed binaries are for inspection and supported upload workflows, not source recovery.
2. Inspect before changing anything
LaunchLayer records project identity, source evidence, framework/build hints, identifiers, versions, assets, credentials, and provider state. It uses those facts to determine the safest next action instead of assuming every project follows the same path.
3. Configure the native shell
For supported wrapper projects, LaunchLayer prepares Capacitor-oriented configuration, native capability requirements, store metadata guidance, permission copy, dependency/setup instructions, and release checklists. A generated plan is not the same as completed app-specific implementation or device verification.
4. Prepare signing and store connections
Apple and Google release builds require the correct developer accounts, app identifiers, signing material, store records, and permissions. LaunchLayer can validate and use configured credentials for supported operations, but Apple, Google, GitHub, RevenueCat, Firebase, and other providers remain independent systems with their own rules.
5. Build using the path your project supports
Legacy hosted-wrapper cloud builds use generated GitHub repositories and GitHub Actions. Existing signed binaries can move to inspection and supported direct-upload flows. GitHub/ZIP Source Build V2 currently performs controlled inspection/readiness work; arbitrary-source V2 compilation remains disabled until its isolated runner boundary is released.
6. Validate before upload
LaunchLayer checks release identity, signing/readiness evidence, required assets and metadata, and known mismatch conditions. Passing LaunchLayer checks reduces preventable mistakes but does not mean Apple or Google will approve the app.
7. Upload and monitor
Supported deployment flows upload an already built, correctly signed artifact to the matching store application, preserve job history, surface provider processing state, and keep retry attempts separate. Store processing, declarations, testing tracks, review, rollout, and publication remain controlled by Apple or Google.
8. Repeat for every release
A new version normally means re-inspecting changed source or a new binary, updating version/build identity, regenerating or rebuilding when native inputs changed, validating again, and then uploading the new artifact. LaunchLayer is a release workspace; it does not make a previously signed binary self-updating.