TestFlight is the most powerful release-engineering tool Apple gives you, and most indies use it as a glorified file share. Here is the playbook we run for every Tappa release.
The cohort layout
We maintain three TestFlight cohorts per app:
- Internal — the team. Sees every build the moment CI uploads it.
- Friends and family — about 20 trusted users. Sees every build the day after Internal.
- Public Beta — typically 200–2,000 users depending on the app. Sees milestones, not every build.
We do not invite the entire user base. We pick public-beta candidates from a Google Form linked from the app's Settings screen, and we curate. A useful beta tester is one who reports clearly, files reproducible bugs, and tells us what the experience felt like.
The release timeline
For a typical monthly release:
- Day 0 — Feature freeze. Code goes to Internal cohort.
- Days 1–3 — Internal testing. Bugs filed, fixed, re-uploaded.
- Day 4 — Friends and Family cohort.
- Days 5–7 — Friends and Family testing. Mostly UX feedback now, fewer bugs.
- Day 8 — Public Beta.
- Days 9–14 — Public Beta in the wild. We watch crash reports, watch reviews-by-version-string, fix anything urgent.
- Day 15 — Submit to App Store.
- Phased release — 1% day 1, 2% day 2, 5% day 3, 10% day 4, 20% day 5, 50% day 6, 100% day 7. We pause the rollout if anything is wrong.
What we look at
During beta and during the phased rollout, we watch:
- Crash-free rate for the build vs the previous build. A drop of more than 0.3% pauses the rollout.
- App Store rating velocity for the new version. A spike in 1- and 2-star reviews about a specific feature triggers an investigation.
- Subscription cancellation rate per build. Worth catching early; sometimes a release accidentally introduces a paywall regression.
What we send to beta testers
A short, plain-language note in TestFlight's release notes:
## What's new in this beta
- Faster export
- New export format: PDF
## What we want you to test
- Try exporting at least one receipt as PDF and reply with how it went.A specific ask gets specific feedback. "Try out the new build" gets nothing.
Phased release — actually use it
Apple's phased release for iOS is genuinely good and most indies turn it on once and never look at it. We watch the dashboard daily during a rollout. If something looks wrong, we pause. If it gets worse, we pull and ship a fix. The cost of being able to abort a release is enormous; it is the difference between a bad day and a bad week.
Three small habits
- Always increment the build number on every TestFlight upload. CI does this automatically. Manual edits introduce confusion.
- Never ship to TestFlight on a Friday afternoon. If something breaks, you will be debugging on Saturday.
- Keep a
RELEASE.mdchecklist at the top of each release branch. Boring, repeatable, immune to forgetting.
TestFlight is your first defence against shipping a regression to a million users. Use it like one.