Apple's TestFlight lets you invite up to 100 internal testers and up to 10,000 external testers, and a build can be tested for up to 90 days. From a security view, treat a beta as a real release to real people: control who is invited, expire old builds, and keep secrets out of the app.
What Apple documents
Apple's App Store Connect help states these points.
- Internal testers: up to 100 App Store Connect users who have access to your content.
- External testers: up to 10,000 people.
- Build expiry: a build is available for testing for up to 90 days, then becomes unavailable.
- Review: when you add the first build to an external group, it goes to App Review. Only the first build requires review, and later builds may not need a full review.
- You can expire a build to stop testing. If you do not expire a build and you submit it to the App Store, invited testers can keep testing it after it goes live.
Why this matters for security
Your beta is a distribution channel. People install it on personal phones, often with real accounts. Common issues follow from that.
- Debug settings left on. A beta often has verbose logging, test endpoints and relaxed checks. Strip or gate them.
- Real data in test builds. Pointing a beta at production data exposes it to a wider group. Use a test backend.
- Stale builds. A vulnerable build lingers until it expires. Expire it when a fix ships rather than waiting for 90 days.
- Tester list drift. Invite lists grow and are rarely pruned. Review them on a schedule.
- Embedded secrets. Anything shipped inside the app can be extracted. Do not ship API keys with more power than the beta needs.
Internal versus external
Use internal testers for staff who already have access to your account. Use external groups for outside users, and consider smaller groups so you can reach everyone when something goes wrong. Note that Apple says managed Apple Accounts created in reserved domains cannot be used to test builds, so plan tester onboarding with that in mind.
A short beta checklist
- Separate test and production backends.
- Review the build for debug flags before upload.
- Keep a list of who has access and why.
- Expire builds when they are superseded.
- Treat crash logs and feedback as data that may hold personal information.
For the release stage, see our mobile app release security checklist.
Handling feedback and crash data
Beta feedback often arrives with screenshots, device details and logs. Those can include names, messages or tokens. Decide where feedback goes, who can read it, and how long you keep it. Tell testers what you collect. Scrub tokens from logs before they leave the device, and avoid asking for screenshots of screens that show account data.
Quick check
Do all TestFlight builds go through App Review?
Apple says only the first build added to an external group requires review, and later builds may not need a full review.
What happens to a build after 90 days?
It becomes unavailable to testers, according to Apple's help page.
Sources
Last reviewed: 19 October 2026.
