The TestFlight setup nobody documents
Your tester keeps landing on Apple’s developer site. Here’s the order that actually works.
TestFlight is how you hand a build to real people before the App Store. It’s also where everyone loses an afternoon, because the invite flow has an order nobody tells you.
The dead end: you send the link, your tester taps it, and it dumps them on developer.apple.com or a “redeem code” screen that goes nowhere. They didn’t do anything wrong. The phone just wasn’t ready for the link.
The order that works
- Tester installs the blue-propeller TestFlight app from the App Store.
- They open it, accept the agreement, and close it. This “primes” the phone.
- Now they tap your invite link. It opens in TestFlight. Install. Done.
Skip step 2 and the link has nowhere to land.
Two more things
- Testers test inside the TestFlight app, not a website. Non-technical folks keep drifting to developer.apple.com — steer them to the blue propeller, full stop.
- Internal vs external. Internal testers (your own team) get a build instantly, no review. External testers (anyone, by email or public link) wait on a one-time Beta App Review per build — so a fresh build sits in review and they keep seeing the old one. If a tester “isn’t getting your latest fix,” that’s why. Use internal when you need a specific build in someone’s hands now.
One nicety: purchases run in the sandbox here automatically — free, no codes — so testers can exercise your paywall without paying.
The full playbook — every screen, in order — is in the guides.
Rather not wrestle with this yourself?
We handle the App Store Connect and Google Play submission for you — the listing, the errors, the resubmits — and get your app into review. See App Submission →