LaunchLint Academy
The short answer
- Anything shipped in a mobile client must be treated as readable. `.env`, EAS secrets, obfuscation, or an obscure variable name cannot keep a value secret when the bundle, resource, or native configuration needs it.
- Separate public client identifiers from private credentials, move privileged operations to a server, and rotate exposed secrets instead of only deleting them from the current commit.
- This checklist is not a one-time content exercise. Run it before the first store upload, after relevant dependency or configuration changes, and again immediately before release. Engineering, product, and the person controlling the store console must assess the same build. Static repository signals are valuable because they are reproducible, but they do not prove runtime behavior or backend responses. Combine them with tests of the signed artifact, official store declarations, and a recorded release decision.
1. Inventory and classify secrets
List API keys, service credentials, private tokens, signing material, and public client identifiers with owner and allowed location.
Treat inventory and classify secrets as a reviewable property of the exact release candidate. Link the decision to the responsible file, store field, or reproducible device test. Record expected and observed behavior separately, assign an owner, and stop publication while a security or review contradiction remains unresolved.
Release review evidence
- Production state for inventory and classify secrets identified
- Affected project file or store setting linked
- Check repeated on a clean device
- iOS and Android differences recorded
- Every open question has an owner and date
- Evidence contains no secrets or personal test data
2. Review repository and history
Search source, configuration, CI, examples, assets, patches, and Git history; deleted plaintext may remain compromised.
Treat review repository and history as a reviewable property of the exact release candidate. Link the decision to the responsible file, store field, or reproducible device test. Record expected and observed behavior separately, assign an owner, and stop publication while a security or review contradiction remains unresolved.
Release review evidence
- Production state for review repository and history identified
- Affected project file or store setting linked
- Check repeated on a clean device
- iOS and Android differences recorded
- Every open question has an owner and date
- Evidence contains no secrets or personal test data
3. Separate build time from runtime
A CI or EAS secret stays server-side only when its value is never written into client code, app configuration, or generated resources.
Treat separate build time from runtime as a reviewable property of the exact release candidate. Link the decision to the responsible file, store field, or reproducible device test. Record expected and observed behavior separately, assign an owner, and stop publication while a security or review contradiction remains unresolved.
Release review evidence
- Production state for separate build time from runtime identified
- Affected project file or store setting linked
- Check repeated on a clean device
- iOS and Android differences recorded
- Every open question has an owner and date
- Evidence contains no secrets or personal test data
4. Treat public variables as public
`EXPO_PUBLIC_` and equivalent client values are readable in compiled code and belong only to non-privileged configuration.
Treat treat public variables as public as a reviewable property of the exact release candidate. Link the decision to the responsible file, store field, or reproducible device test. Record expected and observed behavior separately, assign an owner, and stop publication while a security or review contradiction remains unresolved.
Release review evidence
- Production state for treat public variables as public identified
- Affected project file or store setting linked
- Check repeated on a clean device
- iOS and Android differences recorded
- Every open question has an owner and date
- Evidence contains no secrets or personal test data
5. Move privilege to the backend
Private provider keys and administrative operations sit behind an authenticated server endpoint with authorization, limits, and audit logs.
Treat move privilege to the backend as a reviewable property of the exact release candidate. Link the decision to the responsible file, store field, or reproducible device test. Record expected and observed behavior separately, assign an owner, and stop publication while a security or review contradiction remains unresolved.
Release review evidence
- Production state for move privilege to the backend identified
- Affected project file or store setting linked
- Check repeated on a clean device
- iOS and Android differences recorded
- Every open question has an owner and date
- Evidence contains no secrets or personal test data
6. Restrict publishable keys
Where an SDK requires a public key, restrict it by bundle ID, package name, signing identity, domain, API, quota, and environment.
Treat restrict publishable keys as a reviewable property of the exact release candidate. Link the decision to the responsible file, store field, or reproducible device test. Record expected and observed behavior separately, assign an owner, and stop publication while a security or review contradiction remains unresolved.
Release review evidence
- Production state for restrict publishable keys identified
- Affected project file or store setting linked
- Check repeated on a clean device
- iOS and Android differences recorded
- Every open question has an owner and date
- Evidence contains no secrets or personal test data
7. Rotate findings and assess history
Revoke first, provision a replacement safely, and inspect usage; renaming or obfuscating the value is not remediation.
Treat rotate findings and assess history as a reviewable property of the exact release candidate. Link the decision to the responsible file, store field, or reproducible device test. Record expected and observed behavior separately, assign an owner, and stop publication while a security or review contradiction remains unresolved.
Release review evidence
- Production state for rotate findings and assess history identified
- Affected project file or store setting linked
- Check repeated on a clean device
- iOS and Android differences recorded
- Every open question has an owner and date
- Evidence contains no secrets or personal test data
8. Automate a release gate
Combine deterministic patterns, entropy signals, an allowlist for genuine public keys, and human review so findings are neither ignored nor blindly blocked.
Treat automate a release gate as a reviewable property of the exact release candidate. Link the decision to the responsible file, store field, or reproducible device test. Record expected and observed behavior separately, assign an owner, and stop publication while a security or review contradiction remains unresolved.
Release review evidence
- Production state for automate a release gate identified
- Affected project file or store setting linked
- Check repeated on a clean device
- iOS and Android differences recorded
- Every open question has an owner and date
- Evidence contains no secrets or personal test data
Frequently asked questions
Are `.env` files secure in mobile apps?
Only as local or server-side input. A value embedded in the client can be extracted.
Do EAS Secrets protect values from app users?
They protect the build process, not a value that is inserted into client code.
Does obfuscation solve the problem?
No. It raises analysis effort but is not secret management.
What should happen after discovery?
Revoke or rotate, inspect use, remove the source, and redesign so the client no longer needs a private secret.