TestFlight is Apple's beta testing service in App Store Connect. You can invite up to 100 internal testers from your team, with no review needed, and up to 10,000 external testers by email or public link once a build passes Beta App Review. Builds stay available for 90 days. Testers send feedback and screenshots from the TestFlight app, and crash reports appear in App Store Connect and Xcode.
Internal vs external testers
Internal testers are members of your App Store Connect team with an appropriate role. You can add up to 100, and they can test builds as soon as processing finishes, without Beta App Review. Use internal testing for daily QA, design review, and stakeholder previews where speed matters more than scale.
External testers are anyone with an email address or your public link. You can have up to 10,000 per app, organized into groups. The first build of each version sent to external testers needs Beta App Review, which checks the build against the App Review Guidelines in a lighter way. Later builds of the same version often go through faster.
Set up test information properly
Before inviting external testers, fill in the test information: a beta app description, what to test, a feedback email, a privacy policy URL, and sign-in details if the app needs an account. Clear instructions produce focused feedback. A vague what to test field produces vague replies or none at all.
Treat Beta App Review like a smaller version of App Review. Provide a working demo account, explain hardware or location requirements, and make sure the build does not crash on launch. The same habits will speed up your production submission, covered in our guide to publishing on the App Store.
Public links and recruiting testers
A public link lets anyone with the link join a group, up to a limit you set. It is the easiest way to recruit from a waitlist, a community, social media, or a Product Hunt launch. Set a tester limit so a viral post does not flood a fragile build, and you can disable the link at any time.
Recruit testers who resemble your target users rather than friends who will be polite. A short screener survey before sharing the link helps you pick people with the right devices, use cases, and motivation. Their feedback is also a rich source of user vocabulary for keyword research and screenshot captions.
Builds, groups, and expiry
Each build is available to testers for 90 days from upload, after which it expires and testers must move to a newer build. Plan release cadence so active testers always have a current build, and use groups to send different builds to different audiences, such as a stable group and an experimental group.
TestFlight supports iOS, iPadOS, macOS, tvOS, watchOS, and visionOS apps. Testers install the TestFlight app and receive update notifications automatically. Expired or abandoned builds frustrate testers, so retire old groups when a test ends and thank participants.
Collect feedback and crash data you can act on
Testers can send feedback with screenshots directly from the app, and TestFlight records crash reports with device and OS details. Review these in App Store Connect or the Xcode Organizer, tag them by theme, and close the loop with testers when you fix something. Responsive teams get better feedback in the next round.
Use beta data to protect your launch rating. Crashes found in TestFlight never reach the store, and stability affects both ratings and visibility, as explained in crash rate and store ranking. Testers who enjoyed the beta are also good candidates to rate the app after launch, within the rules covered in our iOS rating prompt guide.
Common TestFlight mistakes
The most frequent mistake is treating external testing as a formality. Teams send a build to hundreds of people with no instructions, receive a handful of vague comments, and conclude that beta testing does not work. Another is letting builds expire during a long test, which silently removes access and makes the app look abandoned to the very people you want as early advocates.
Teams also forget that TestFlight feedback is not a substitute for analytics. Testers who report nothing may still be churning on day two. Instrument the beta build with the same events you plan to use in production, so you can see activation and retention alongside written feedback, and compare them with the benchmarks in our guide to retention rate.
A worked example: a two-stage beta before launch
A habit tracker starts with 15 internal testers for two weeks to stabilize core flows. It then opens a public link capped at 500 people from its waitlist, with a screener that asks about current habit tools. The what to test field asks testers to complete three days of check-ins and report anything confusing.
Feedback reveals that testers call the feature streaks, not chains, so the team updates in-app copy, screenshot captions, and the subtitle. Crash-free sessions rise above 99.5% before submission. On launch day, the team invites engaged testers to download the public version, building early ratings from real users. The approach mirrors the pre-launch ASO strategy guide.
How to do it, step by step
- Upload a build and test internallyUpload from Xcode, add internal testers from your team, and fix launch-blocking issues before going external.
- Write test informationAdd a beta description, specific what to test instructions, a feedback email, a privacy policy URL, and demo credentials.
- Submit for Beta App ReviewSend the first external build for review, with the same care you would give a production submission.
- Recruit with a capped public linkShare a public link with a tester limit to a screened audience that matches your target users.
- Triage feedback weeklyTag feedback and crashes by theme, fix the highest-impact issues, and tell testers what changed in the next build.
Before and after examples
Illustrative examples written for a generic app in this category, not client results. Swap in your own product, audience, and data.
Please test the app.
Create a habit, check in daily for three days, and try editing the reminder time. Tell us anything that felt confusing.
Why it works: Specific tasks produce specific, comparable feedback.
Posted with no limit.
Capped at 500 testers and shared with a screened waitlist segment.
Why it works: A cap protects a fragile build and keeps feedback manageable.
Silently ship fixes.
Build notes: Fixed the reminder bug many of you reported. Thank you, keep it coming.
Why it works: Testers who see their impact give more feedback in later rounds.
Action plan
- Stabilize with internal testers first
- Write specific what to test instructions
- Cap public links and screen testers
- Watch the 90-day build expiry
- Triage feedback and crashes weekly
- Convert engaged testers into launch-day users
Metrics to monitor
- Crash-free sessions in beta
- Feedback items per active tester
- Tester retention between builds
- Issues fixed before launch
Record the baseline, release date, audience, markets, and external changes before interpreting movement. Rankings and conversion are useful signals, but a decision is stronger when activation, retention, and business value confirm that the page attracted the right users.
Frequently asked questions
How many testers can TestFlight have?
Up to 100 internal testers from your App Store Connect team and up to 10,000 external testers per app.
Do TestFlight builds need review?
Internal builds do not. The first build of each version sent to external testers needs Beta App Review.
How long do TestFlight builds last?
Each build is available for 90 days from upload. After that it expires and testers need a newer build.
Is TestFlight free?
Yes. TestFlight is included with the Apple Developer Program, and testers install the free TestFlight app.
Keep reading
More in Platform Guides
Browse all 9 Platform Guides guides
Work with ASOWin
Primary sources
Platform capabilities and limits can change. Verify current requirements in these official resources:
