What the wrapping service actually does
A wrapper places a web experience inside a native iOS/Android shell; it does not magically convert every web feature into a native one.
Hosted web wrapper
A supported live-URL path packages a native shell that loads the configured HTTPS web experience. This is useful when the product is primarily web-based and the live site is intentionally the runtime source.
Bundled web assets
When a project has buildable web source and a supported package path, web assets can be prepared for inclusion inside the native project. The exact behavior depends on the source/build path and generated configuration.
Capacitor layer
LaunchLayer uses Capacitor-oriented native project structure for supported wrapper workflows. Capacitor provides the bridge between JavaScript/web UI and native iOS/Android capabilities through plugins and platform code.
Native features
Capabilities such as push notifications, biometrics, camera access, deep links, in-app purchases, files, location, and social login require the correct plugins, platform configuration, permissions, external provider setup, app logic, and device testing. Selecting or generating a feature plan does not by itself finish those external or app-specific steps.
What stays web
Your web application's UI, backend, authentication model, APIs, and business logic remain your responsibility unless a specific LaunchLayer workflow explicitly changes or generates part of them.
What cannot be recovered
An uploaded IPA/APK/AAB is compiled output. LaunchLayer can inspect supported metadata and use supported deployment paths, but it does not reconstruct the original source code or safely bolt arbitrary new native features into a signed binary.
When a rebuild is required
Changes to bundle/package identity, native plugins, entitlements, permissions, signing, app icon embedded in the binary, native SDK configuration, or compiled code normally require a new native build. Store-listing-only changes may not require a binary rebuild.