TestFlight Beta Testing: A Practical Guide for Small iOS Teams
Last updated
TestFlight is Apple's beta testing service. For a small iOS team it is the cheapest way to find out whether a build is ready before strangers on the App Store find out for you. This guide explains how TestFlight is organised, how internal and external testing differ, and the habits that make a beta worth the effort. Apple's figures below come from its own pages as of 15 January 2026.
Shipping on Android too? The Google Play version of this guide is Google Play Testing Tracks: Internal, Closed and Open Testing.
The short version
- Internal testing is for up to 100 people on your App Store Connect team, and their builds skip review.
- External testing reaches up to 10,000 people per app, by email invite or public link. The opening build of each version goes through TestFlight App Review.
- A build stays available to testers for 90 days, so plan your build cadence around that.
- Clear test notes and quick replies matter more than the number of testers.
How TestFlight is organised
Everything lives in the TestFlight tab of your app in App Store Connect. You upload a build from Xcode or Xcode Cloud, add it to one or more tester groups, and testers install it with the free TestFlight app. As of 15 January 2026, Apple's TestFlight page says you can share up to 100 builds and test several at once, and that a tester can use your beta on up to 30 devices. You never collect device UDIDs or make provisioning profiles for testers.
Groups are the unit you work with. A group has testers and builds. A typical small team keeps one group for itself, one for a handful of trusted customers, and one larger group filled from a public link.
| Internal testing | External testing | |
|---|---|---|
| Who | App Store Connect users with the Account Holder, Admin, App Manager, Developer or Marketing role | Anyone you invite by email or who joins by public link |
| How many | Up to 100 | Up to 10,000 per app |
| Review | None | TestFlight App Review for the opening build of a version |
| Build lifetime | 90 days | 90 days |
Sources: Apple's TestFlight overview and the App Store Connect Help pages on TestFlight, internal testers and external testers, as of 15 January 2026.
Internal testing: your team, no review
Internal testers are people already on your App Store Connect team. Because Apple treats them as trusted, their builds skip review, which makes internal groups the right home for daily builds. When you create an internal group you can let Xcode deliver each new build to the group as it arrives, or add builds by hand. Apple notes that builds made by Xcode Cloud always have to be added to groups by hand.
Xcode and Xcode Cloud can also upload a build marked for internal testing. Such a build can go to internal groups and nowhere else: not to external testers and not to the App Store. That suits debug builds with extra logging, or feature flags you never want a customer to see.
For a team of two or three, internal testing can carry you a long way. Install every build on the oldest device you support, and ask a teammate who did not write the feature to try it cold.
External testing: real users, with a review step
External testers are people outside your team: customers, friends, a community around your app. To reach them you create an external group (App Store Connect asks you to have an internal group before you can make one), add a build and fill in the test information. Apple's help says the opening build you submit for a version gets a full TestFlight App Review, and later builds of the same version might not. You can have one build of each version in review at a time.
External testing needs a beta app description, a feedback email and beta app review information. The description goes into the invite your testers see, so write it for testers, not for Apple.
Email invites or a public link
Email invites suit a small group you already know. Each tester's name and email show in App Store Connect next to their installs, sessions and crashes. A public link suits a wider call, such as a newsletter post or a banner inside your app. Apple lets you cap a public link at any number from 1 to 10,000 testers, and set criteria such as device type and OS version so people on hardware you do not support cannot join. People who join by link appear as anonymous.
Anyone who has the link can pass it on. To stop new people joining, set a tester limit or disable the link.
Build expiry and cadence
Apple's overview says a build becomes unavailable to testers after 90 days. Invited testers can keep using a build after that version goes live on the App Store, until it expires. Two practical points follow:
- If a beta runs longer than about three months, send a fresh build before the old one expires, or your most loyal testers are left with nothing to open.
- Keep build numbers moving in a clear sequence. Testers can see every build you have shared with them, and a tidy sequence makes it easy for them to say which one misbehaved.
Habits that make a beta worth running
Say what to test
Every build has What to Test notes. Use them. "Download a large offline map on a slow connection and tell us if the progress bar is honest" gets better answers than "bug fixes and improvements".
Give each group a purpose
A group that tests everything tests nothing in particular. Keep a small group for risky changes and a wider one for release candidates. Remove testers who never install; they make your numbers look healthier than they are.
Decide what "ready" means before you start
Write down what must be true before you submit to App Review. For example: no crash reports on the main flows for a week, and every report from the last build answered. Without a line in the sand, betas drift.
Answer people
Testers who hear back keep testing. A one-line reply to a screenshot report ("thanks, fixed in the next build") is worth more than a long survey. Our guide to TestFlight feedback covers where those reports land and how to work through them.
From beta to release
When a build is good enough, you do not upload it again. Builds you have added in TestFlight show up in App Store Connect, and you pick one for your App Store version and submit it for review. One frequent reason a fresh build cannot be tested at all is a Missing Compliance status, covered in TestFlight Missing Compliance. Once the release is approved, a phased release lets you roll it out gradually.
How FeedbackKit fits in
TestFlight handles builds, crashes and bug reports. It is not the place to decide what to build next. FeedbackKit is: users post feature requests and vote on them inside your app, through the SwiftUI views in the Swift SDK.
FeedbackKit's six statuses are Pending, Approved, In Progress, TestFlight, Completed and Rejected. When a requested feature lands in a beta build, move the request to TestFlight. Everyone who voted for it sees in the app that it is in beta, and the person who asked for it can be emailed about the change. Those voters are also your best external testers for that feature, because they asked for it. Share your public link with them and you will hear from people who care.
You run this from the FeedbackKit admin app on iPhone, iPad and Mac. Requests can be sorted by the total MRR of the users behind them, so a beta of a feature your paying customers asked for is easy to spot. Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:
From request to beta
If you want a method for choosing what goes into the next beta, start with our overview of prioritisation frameworks. And if you want your users' requests, votes and that TestFlight status in one place, start free with FeedbackKit.