# LaunchLayer Integration Architecture

Canonical page: https://launch-layers.cloud/help/integration-architecture
Last updated: 2026-10-02

This document summarizes how LaunchLayer connects to external systems. Provider state is authoritative when it conflicts with LaunchLayer state.

## GitHub
Production wrapper and cloud-build workflows use the connected GitHub account and GitHub Actions for supported build and deployment jobs. LaunchLayer can create or use a configured private build repository and record workflow/run evidence. GitHub permissions, repository access, Actions availability, quotas, secrets, and runner behavior remain controlled by GitHub.

Arbitrary GitHub Source Build V2 compilation is still planned. Current V2 behavior is source inspection plus a deterministic readiness contract, not unrestricted customer-code execution.

## Apple Developer and App Store Connect
Production Apple workflows support exact-app binding, credential validation, signed-IPA deployment, supported listing/localization/review-information updates, age rating, accessibility, TestFlight configuration, export compliance, availability, app settings, pricing, Apple IAP/subscription metadata, review submission, and release controls where provider APIs support them.

Mutating operations require configured credentials, exact app/version identity, explicit confirmation where applicable, and provider read-back or state verification. Apple controls processing, policy review, approval, and final provider state.

## Google Play
Production Google workflows support matching Android artifact deployment plus supported listing text, contact details, supported images, Data Safety, tester groups, monetization catalog data, release tracks, and staged-rollout controls.

These require exact package/application binding and configured Google service-account access. Google controls processing, Play Console-only declarations, policy review, and final publication state.

## RevenueCat and purchases
LaunchLayer currently provides monetization setup guidance, store-product synchronization/audit evidence, client-safe RevenueCat configuration checks, and a Purchase & Subscription Test Lab that records real Apple Sandbox/TestFlight or Google Play test outcomes.

The separate hosted RevenueCat IAP manager for automatically managing RevenueCat products, entitlements, offerings, packages, webhooks, and synchronized customer state remains planned.

## Push, Firebase, APNs, and analytics
Native setup plans can describe dependencies, configuration, permissions, provider setup, and device tests. The managed Hosted Push Center using APNs/FCM and live provider-adapter Release Analytics remain planned. Post-Launch Health currently records dated evidence snapshots rather than claiming live telemetry.

## Base44 and other app builders
LaunchLayer can accept supported Base44, React, Vite, and other web-app starting points through a live URL, GitHub repository, or source ZIP. The original builder remains responsible for its own runtime, backend, auth, database, and source. LaunchLayer prepares the mobile release path; it does not automatically migrate another platform's backend.

## AI Project Agent
The Project Agent reads only authenticated, project-scoped LaunchLayer evidence and can prepare only allowlisted local-setting proposals. It cannot directly mutate credentials, signing, binaries, provider records, store-review actions, or paid builds. Supported local changes and the allowlisted stale-state repair require explicit approval and state revalidation.

## Credential handling
Credentials belong only in designated secure LaunchLayer or provider fields. Do not paste private keys, passwords, certificates, API secrets, webhook secrets, or signing material into Project Agent chat, public support text, screenshots, or source control.

## Verification sequence
1. Confirm the exact LaunchLayer project and app identity.
2. Confirm the intended external account, team, and application.
3. Validate the credential or OAuth connection.
4. Run the narrow supported read or preflight operation.
5. Preview any mutation.
6. Explicitly approve it.
7. Read back provider state or durable LaunchLayer evidence.
8. Keep attempts in history rather than overwriting them.
9. Test released behavior in the real target environment when required.

## Production versus planned
Implemented as described: hosted-wrapper builds, signed-binary deployment, Apple/Google publishing workflows, monetization sync audit, purchase test evidence, release monitoring, and the guarded Project Agent.

Planned: arbitrary Source Build V2 compilation, Hosted Push Center, the full hosted RevenueCat IAP manager, and live provider-adapter release analytics.