In this article

Use internal TestFlight testing for eligible App Store Connect users on your team, and external testing for an audience that should not need that account access. Build readiness, group assignment and invitations still matter in both routes. Giving someone admin access is not a sensible shortcut for ordinary beta recruitment.

Apple's TestFlight overview, checked October 8, 2026, lists up to 100 internal App Store Connect users with content access and up to 10,000 external testers. Those limits do not guarantee that a particular build or user is eligible.

Choose the audience before the workflow#

An internal QA engineer who already has appropriate app access may fit the internal route. A customer volunteer, freelance evaluator or wider community generally needs a different access model.

Write down why each group exists, who manages it and which builds it should receive. Separate release candidates from experimental builds so an invitation does not unexpectedly move someone onto a different test stream.

Avoid collecting more tester information than the supported invitation process requires. Use private channels for feedback that could contain account or device details.

Distinguish beta review from public-store review#

Apple's overview explains that external builds may need review and that subsequent builds may not require a full review. Do not promise that every future external build will bypass review, or that beta approval is approval for public App Store distribution.

Internal availability does not prove the external path is open. Keep the intended audience in the release record beside the exact build number.

Assign a build deliberately#

Create or select the appropriate group and confirm the build assigned to it. Check the build's current status and any export-compliance requirement. Then use the supported invitation path and verify that a representative authorized tester accepted it and installed the intended build.

A group name alone is not evidence that it contains the current release candidate. An old invitation can point to an expired or different build.

A useful access checklist is:

text
Audience and group:
Build version/number:
Current build status:
Review/compliance requirement:
Build assigned:
Invitation accepted:
Installation verified:
Feedback owner:

Keep this separate from your CI success record.

Plan renewal and feedback#

Apple describes a 90-day testing window in its TestFlight workflow. Account for that window in a long beta. Decide who will supply the next build and how testers will be informed when the build changes.

Give testers a focused task and a clear private feedback path. “Please test everything” is less actionable than asking someone to complete the main workflow and report the first point where the result diverges from expectations.

For a hypothetical note-taking app, one group could verify account recovery while another checks offline editing. These are editorial examples, not Apple-mandated test groups.

Grant the access the person actually needs#

Use your team's account-management process for internal users and the external testing path for people who need only beta access. Do not add permissions solely to make an invitation problem disappear.

If installation fails, inspect the exact build status and group assignment before altering roles. Our passkey recovery guide covers a related account-access principle: understand the recovery and eligibility path rather than assuming a convenient login method proves access to every resource.