LaunchLint Academy
The short answer
- Permissions are product behavior, platform configuration, and a privacy promise at the same time. Request only access required by a current feature and explain it specifically at the moment of use.
- Review iOS purpose strings, Android manifest declarations, runtime flow, denial, and fallback together. A permission without a reachable feature is as suspicious as a feature without matching configuration.
- 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 permissions
Map every iOS usage description and Android permission to a real feature, SDK, and data purpose.
Treat inventory permissions 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 permissions 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. Minimize access
Prefer photo pickers, system intents, approximate location, or manual input when the feature works without broad access.
Treat minimize access 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 minimize access 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. Write specific purpose strings
Explain in user language which feature needs access and what happens next; generic wording does not establish trust.
Treat write specific purpose strings 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 write specific purpose strings 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. Ask in context
Request access when the user starts the feature and explain unusual needs before presenting the system dialog.
Treat ask in context 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 ask in context 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. Respect denial
The app must not crash or block its entire core; provide a useful fallback and settings path where appropriate.
Treat respect denial 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 respect denial 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. Reconcile framework configuration
Expo config plugins, React Native packages, Flutter plugins, and native files may add permissions or override text.
Treat reconcile framework configuration 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 reconcile framework configuration 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. Synchronize privacy declarations
Permission, actual collection, privacy policy, App Privacy, and Data Safety must describe the same practice.
Treat synchronize privacy declarations 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 synchronize privacy declarations 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. Test the release build
Cover first request, denial, repeat request, permanently denied state, limited selection, and upgrades from older installs.
Treat test the release build 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 test the release build 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
Does every iOS protected resource need a purpose string?
Use the matching usage description for protected access. Missing or vague text can cause runtime and review problems.
Should onboarding request every permission?
No. Ask in feature context and request only necessary access.
Can a plugin add permissions?
Yes. Inspect the resulting native configuration and remove or block unnecessary access.
Can LaunchLint verify request timing?
Not completely. Static files show configuration signals; timing and user experience require runtime testing.