LaunchLint Academy
The short answer
- TestFlight distributes beta builds but does not automatically submit them to the App Store review. You choose one version and the exact build whose metadata, access, and privacy declarations are complete.
- Use beta feedback as release evidence, freeze the candidate, and treat review, publication, and monitoring as separate decisions.
- 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. Define beta goals and groups
State which risks internal and external testers must cover instead of using TestFlight as a download channel only.
Treat define beta goals and groups 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 define beta goals and groups 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. Freeze the exact build
Tie build number, commit, environment, feature flags, and test data together; a later upload is a different candidate.
Treat freeze the exact 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 freeze the exact 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
3. Plan external beta review
External groups may require Beta App Review. Account for information and lead time without confusing it with final App Review.
Treat plan external beta review 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 plan external beta review 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. Triage feedback and crashes
Classify reports as blockers, regressions, or improvements and document deliberately accepted residual risk.
Treat triage feedback and crashes 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 triage feedback and crashes 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. Complete the App Store version
Select the build and finish required metadata, privacy, age rating, export, and review-access information.
Treat complete the app store version 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 complete the app store version 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. Test review notes
A fresh tester must reach login, purchases, hardware flows, and protected features using only the submitted instructions.
Treat test review notes 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 review notes 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. Control statuses and replies
Distinguish review and rejection states, then respond with a concrete path and supporting detail.
Treat control statuses and replies 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 control statuses and replies 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. Plan release and rollout
Automatic, manual, or phased release requires an owner, monitoring, stop criteria, and a response plan.
Treat plan release and rollout 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 plan release and rollout 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 TestFlight submit my app to App Review?
No. TestFlight is beta distribution; the App Store version and selected build are submitted separately.
Can I keep one beta build forever?
No. TestFlight builds have a limited testing period, so do not treat a beta artifact as permanent.
Does every binary fix require a new build?
Yes. When the binary changes, upload a new build and repeat affected acceptance checks.
Can LaunchLint run TestFlight crash tests?
No. LaunchLint reviews files statically; crash and device telemetry require separate analysis.