Credentials, signing, secrets, and account ownership
The safest release setup keeps ownership with the customer's developer accounts and separates public client configuration from private signing/server secrets.
Apple
Use the intended Apple Developer/App Store Connect team, bundle identifier, certificates/profiles or supported signing method, and App Store Connect API credentials with only the permissions required for the operation. Expired, mismatched, or wrong-team signing material will break distribution.
Use the intended Play Console application/package and service credentials with the minimum permissions needed. Package identity and version codes must match the release target.
GitHub
Repository access and Actions execution are governed by the connected GitHub account, repository permissions, secrets, branch state, Actions quotas, and provider availability.
RevenueCat
Client applications use RevenueCat public platform SDK keys. Secret API keys and webhook secrets belong in trusted server-side environments, not bundled into the mobile client.
Other providers
Firebase/APNs, social login, maps, analytics, crash reporting, payment providers, and similar integrations each have their own client IDs, server secrets, certificates, redirect URIs, entitlements, or console configuration. A LaunchLayer checklist does not replace those provider requirements.
Secret handling
Do not paste private keys into public documentation, commit them to source repositories, or embed server credentials in browser/native client code. Rotate credentials if exposure is suspected.
Ownership model
Developer accounts, store listings, signing identity, production domains, provider projects, and customer data should remain under the appropriate owner-controlled accounts. LaunchLayer is a release workspace and orchestration layer, not the legal owner of those external accounts.