Choose the correct build path
LaunchLayer supports different starting materials, and choosing the wrong path is one of the easiest ways to create release confusion.
Live HTTPS URL
Use when you intentionally want a hosted web wrapper. LaunchLayer prepares a native shell around the configured web experience and the release still needs normal signing, testing, store metadata, and review.
GitHub repository
Use when you control source and need source inspection or a supported build-preparation workflow. Legacy hosted-wrapper cloud builds use LaunchLayer-generated repositories; Source Build V2 inspection for arbitrary GitHub source is a separate beta readiness path and does not yet mean arbitrary-source V2 compilation is enabled.
Source ZIP
Use for controlled source inspection when repository access is not the input. ZIP inspection validates archive safety and project-root/build evidence. Source Build V2 arbitrary-source compilation remains disabled until the isolated runner path is released.
Existing IPA
Use for iOS binary inspection and supported direct deployment when the IPA is already correctly signed for the intended application. Do not choose this path expecting LaunchLayer to recover editable iOS source.
Existing APK or AAB
Use for Android binary inspection and supported Play-oriented deployment workflows when the package identity and signing/release requirements are correct.
Existing store app
Connect the corresponding provider when the app already exists in App Store Connect or Google Play. LaunchLayer can compare provider state with local project/build state and help continue the release rather than creating a second identity.
How to decide
If you need to change compiled native behavior, use source plus a rebuild path. If the binary is already correct and you only need inspection, store metadata, or upload, use the existing-build path. If you are unsure, start with the material that is actually authoritative rather than converting it unnecessarily.