TestFlight access: how to add testers for iOS beta testing

Key takeaways

Internal testers (up to 100) must be App Store Connect users and get builds instantly with no review. External testers (up to 10,000) need a Beta App Review for first build of each version.
TestFlight builds expire after 90 days. When they expire, testers lose app entirely, including login state, local data, and any testing progress.
Invitation emails frequently don't arrive. This is a known, years-long Apple issue with no permanent fix. Public links bypass problem but remove your control over who installs.

TestFlight access is how iOS teams distribute beta builds to testers before an App Store release. It's built into App Store Connect, free with $99/year Apple Developer Program membership, and is only practical way to run iOS beta tests at scale. Ad hoc distribution caps at 100 registered device UDIDs. TestFlight supports up to 10,000 external testers.

The process is straightforward when it works. The problems start when invites don't arrive, builds expire mid-cycle, or your team doesn't understand difference between internal and external testing.

Internal vs external testers

TestFlight splits testers into two categories with different limits, review requirements, and access speeds.

	Internal testers	External testers
Maximum	100 per app	10,000 per app
Who can be added	App Store Connect users with a role	Anyone with email or public link
Beta App Review	No	Yes, first build per version
Build access speed	Instant after processing	After review (hours to days)
Invite method	Email	Email or public link
Best for	QA, devs, product managers	Real users, external stakeholders

Internal testers don't count against your 100 registered device UDID limit. That's a real advantage over ad hoc distribution.

How to add internal testers

Before you can add someone as an internal tester, they need to be an App Store Connect user with right role. If they're not already in your team, add them first under Users and Access.

Open App Store Connect and go to your app
Click TestFlight tab
Under Internal Testing in sidebar, click your group (or create one)
Click Invite Testers
Select users you want from list
Click Add

Internal testers get an email invitation immediately after build finishes processing. No review, no wait. They install TestFlight app from App Store, accept invite, and they're testing.

You can set groups to auto-distribute new builds. When enabled, every build you upload goes to that internal group automatically. This is useful for QA teams running daily builds through CI/CD pipelines.

How to add external testers

External testing has one extra gate: Beta App Review. The first build you submit for each version goes through Apple's review before external testers can access it. Later builds of same version usually skip full review and reach testers faster. You'll need an IPA file built with an App Store distribution profile.

Open App Store Connect and go to your app
Click TestFlight tab
Under External Testing in sidebar, click + button to create a group
Name group and click Create
Add a build to group (click + next to Builds)
Click Submit for Review (first build only) or Start Testing (subsequent builds)
Add testers by email: click + next to Testers, enter email addresses
Testers receive an invite email with a link to install via TestFlight app

You can submit up to six builds for Beta App Review within a 24-hour period. After first build of a version passes review, additional builds of that same version typically process in minutes rather than hours.

External testers need the TestFlight app installed on their device. They don't need an App Store Connect account.

Public links: when to use them

Instead of adding testers one by one via email, you can generate a public link that anyone can use to join your beta.

Go to your external testing group
Click Enable Public Link
Copy generated URL

The link works until you disable it, hit your tester cap, or build expires. You can set a maximum number of testers allowed through the link.

Public links are useful when you want to run an open beta, share on social media, or distribute to a large group without collecting email addresses upfront.

The trade-off: you lose control over who installs. Anyone with a link can join. You won't know who your testers are unless they submit feedback through TestFlight's built-in feedback form. For regulated apps, financial services, or healthcare apps, email-based invites with known testers are a safer path.

What goes wrong

The TestFlight setup process looks clean in documentation. In practice, teams hit same problems repeatedly.

Invitation emails don't arrive. This is the most common TestFlight complaint. Apple Developer Forum threads about undelivered invitations go back years, and problems still surface regularly. Testers check spam folders, try alternate email addresses, and nothing works. The workarounds:

Confirm first external build has passed Beta App Review. Invites can't work before that.
Ask testers to check if email landed in Gmail's Promotions tab or was blocked by a corporate email filter.
Use a public link instead. It bypasses email delivery problem entirely.
As a last resort, remove and re-add the tester.

Builds expire and testers lose everything. TestFlight builds expire 90 days after upload. When a build expires, testers can't open the app anymore. Login state, cached data, and any testing progress are gone. If your release cycle stretches past 90 days, your beta testers have to start over from scratch with a fresh build.

The fix: upload a new build with an incremented build number before the previous one expires. The new build gets its own 90-day window. If you keep a regular release cadence (every 2-4 weeks), expiry is never an issue.

Expired builds get sent to new testers. A known bug where invitation emails link to an old, expired build instead of current one. Testers click a link and get an error or download a build that immediately fails. This has been reported on Apple Developer Forums multiple times. The workaround: create a new external testing group, add current build to it, and invite testers through the new group.

"The requested app is not available or doesn't exist." This error appears when testers try to install a build that App Store Connect shows as "Ready to Test." Removing and re-adding testers sometimes fixes it. In some cases, issue is on Apple's infrastructure side and resolves after a few hours.

TestFlight limits in one place

100 internal testers per app
10,000 external testers per app
100 apps can be tested simultaneously per account
90-day build expiry (no extensions, no reactivation)
6 builds can be submitted for Beta App Review within 24 hours
30 devices per tester for testing
Requires $99/year Apple Developer Program membership
Public links: unlimited uses until you cap them or disable link

What to actually test during beta

Adding testers is easy part. Knowing what to test during beta is where most teams under-invest.

Your internal QA team should have already covered functional flows. Beta testing with external users should focus on:

Device and OS coverage. Testers run your app on devices and OS versions your team doesn't own. A tester with an iPhone SE on iOS 16 might catch layout issues your iPhone 15 Pro Max missed.
Network conditions. Real users test on spotty cellular, hotel WiFi, and VPNs. You can't replicate these in a lab.
Onboarding clarity. First-time users hit UX friction your team is blind to because they know the product.
Crash reporting. TestFlight collects crash logs automatically. Monitor these daily during beta, not at the end.
Battery and performance. Background behavior, memory usage, and thermal issues surface on older devices over longer usage sessions that internal testing rarely covers.

This is separate from your mobile app testing checklist. That checklist covers functional testing. Beta testing is about real-world conditions and user behavior you can't script.

Automating beta test flows with Drizz

TestFlight handles build distribution. It doesn't test anything. You still need to verify that every build you push to testers actually works.

The gap most teams fall into: upload a build to TestFlight, wait for tester feedback, find bugs reported by external users that internal QA should have caught first. This happens because running your full regression suite manually before each TestFlight upload takes hours. Teams skip it when release pressure builds.

Drizz automates testing that should happen before a build reaches TestFlight. Upload your IPA to Drizz, run your test plan against real iOS devices, and only push build to TestFlight if tests pass. The flow plugs into CI/CD: your pipeline builds IPA, Drizz runs the suite, and builds moves to TestFlight distribution only after validation.

Because Drizz tests are written in plain English and use Vision AI instead of selectors, the same test suite works across builds without maintenance. When your app's UI changes between beta versions (which it will, that's the point of beta feedback), your tests don't break. That's the difference between a team that catches bugs before testers see them and a team that uses testers as bug catching layers.