Native builds and distribution
Native projects have a separate delivery lifecycle from Web deployment. Use the Native runtime and build controls that appear in the project. The exact actions depend on the configured app identifier, build target, platform, and external credentials.
Prepare the project
Review the project name, app identifier, bundle/package identifiers, version, icons, permissions, and platform-specific configuration. Test the supported device preview and resolve runtime errors before requesting a build. Do not assume that a browser preview proves a native package is ready.
Build and inspect status
Start the available build for the intended platform and watch its job status. A queued or running job is not a completed build. Open the job result and inspect build errors, artifact availability, and signing state. If a build fails, keep its log and fix that failure before starting another build.
Beta and store distribution
Distribution can require Apple Developer or Google Play Console accounts, accepted agreements, signing credentials, app records, and provider authorization. Complete those requirements in the relevant provider. Review the target account and track before submitting. A successful package build does not mean that a store has approved the app.
Changes and release safety
Use a reviewed project checkpoint for a release and retain the build-to-checkpoint association. Do not expose signing keys in project source or the Composer. Follow the status shown by the distribution panel for upload, review, rejection, or release.