How LaunchLayer works

The full release lifecycle in one place, including what LaunchLayer automates, what happens in external services, and where human review is still required.

Use one project-wide preflight to understand readiness, blockers, next build identity, and the safest next action without hunting across every release tab.

A wrapper places a web experience inside a native iOS/Android shell; it does not magically convert every web feature into a native one.

LaunchLayer combines deterministic release checks, provider integrations, generated guidance, and AI-assisted workflows; these are not interchangeable.

Each project has its own AI assistant that reads live LaunchLayer evidence, stays scoped to the authenticated user's project, and routes changes through guarded approval paths instead of silent AI writes.

A truthful map of what LaunchLayer reads, what it can write, what credentials are required, what still happens in the provider, and which integrations are production versus planned.

LaunchLayer supports different starting materials, and choosing the wrong path is one of the easiest ways to create release confusion.

Deployment is a sequence of separate provider states; uploading a build is not the same as publishing it.

The safest release setup keeps ownership with the customer's developer accounts and separates public client configuration from private signing/server secrets.

A released app becomes the starting point for the next release; updates still require identity continuity and, when native inputs change, a new build.

A truthful release guide includes the boundaries: some steps are automated, some are generated assistance, and some always remain external.

Use evidence from the exact project, build, provider, and attempt before changing code or credentials.

A guided app release workspace for source preparation, signed-build inspection, QA, approvals, store setup, configured builds, and deployment.

Use source when rebuilding; use a signed binary for inspection and direct upload; use a store connection to continue an existing listing.

Save reusable store and build settings without copying names, source files, URLs, or credentials.

A hosted wrapper loads your live HTTPS application inside the mobile shell.

Connect a repository and branch for source inspection and guided build preparation.

A ZIP should contain a safe, recognizable project root with source and dependency manifests.

An IPA is a compiled, signed iOS application. Its embedded bundle ID and native code cannot be rewritten by LaunchLayer.

APK is commonly installable; AAB is the Play publishing bundle. Both carry an immutable package name and version identity.

GitHub Actions compiles LaunchLayer’s generated Capacitor wrapper; it does not compile inspected GitHub or ZIP source.

Direct deployment uploads an existing configured binary; it does not rebuild it or guarantee store publication.

Marketplace selections generate native setup and implementation plans; they do not silently create a production backend or complete device testing.

Prepare listing text, screenshots, icons, URLs, privacy information, and console-specific declarations.

Create the publisher accounts, ownership, agreements, and access LaunchLayer needs before store-side work can succeed.

Use store testing to verify the same release candidate you intend to submit or promote.

Start with what the user is buying and where purchase occurs; do not assume StoreKit, Play Billing, or external checkout without confirming the product architecture and storefront scope.

RevenueCat sits between your app and store products; the stores remain the source for product availability and transaction processing.

Release-readiness scans and approval portals create evidence and gates; they cannot guarantee a defect-free app or store approval.

Use the failing stage to decide whether to retry, correct configuration, or produce a new binary.

Use scoped accounts and project permissions, and understand where generated repositories and project records live.

Beta inspection verifies repository access, branch, exact commit, project root, framework, package manager, build script, output, and environment-variable references before any runner dispatch; compilation is planned and disabled.

A typed GitHub URL is not sufficient; the connected account must be able to resolve and read the repository and branch.

Compatibility depends on the selected project root producing static web output that Capacitor can bundle.

Beta ZIP inspection validates integrity and limits before reading source metadata; it does not execute archive contents.

A debug APK supports quick compatibility and device testing; it is not intended for Play production publishing.

Planned: release AAB generation requires protected keystore material and post-build artifact validation.

Certificate Center displays non-secret readiness metadata and expiration warnings without duplicating secret material.

V2 jobs use specific stages and preserve source, configuration, logs, errors, artifacts, and linked retries.

Planned: hosted push remains unavailable until physical-device delivery, authenticated registration, batching, idempotency, invalid-token handling, and tenant isolation are verified.

Planned: IAP management will follow RevenueCat's product-to-entitlement-to-offering model and will not unlock access from a client callback alone.

Planned provider adapters will display only metrics returned by connected Firebase or Sentry services.

Planned roles require server-side permission enforcement; hiding buttons is not authorization.

Planned provider adapters will support templates, preview, test issuance, and logs; dynamic updates remain unavailable until provider services work.

Planned templates remain disabled until native build and physical-device verification workflows exist.

Planned Live Activities remain disabled until native build and verification workflows exist.

Planned roadmap states are controlled by administrators and do not constitute promises.

Current customers stay on legacy_v1; launchlayer_v2 is an unpublished proposal until prices and backend enforcement are connected.