iOS TestFlight is where a build goes before anyone can call it a release.
iOS TestFlight is Apple's way of putting a pre-release build on real phones without shipping it to the App Store. It is not a build server, and it is not a route around review. It is a distribution list with rules attached: a capped number of testers, a fixed lifetime per build, and a review gate in front of anyone outside your own team. Knowing those rules early saves a week later, because most of what goes wrong on the way to publishing to the App Store goes wrong here first.
This page covers what TestFlight is, and how internal and external testing differ. It gives the numbers Apple publishes for tester counts and build expiry. It shows how a TestFlight invite reaches a person, and what has to be true before a first build goes out.
See what expires and whenThe short version
It is a distribution list with a clock attached.
Two kinds of group, two different experiences. Internal testers are App Store Connect users on your own account, capped at 100. External testers are anyone with an email address or a public link, capped at 10,000. The first build you hand them has to be approved by App Review for TestFlight before they can install it.
Everything else follows from the clock. Apple states you can test a build for up to 90 days, and that the build becomes unavailable for testers after that. A beta is therefore a cycle of uploads, not one build you leave standing.
What TestFlight is, and what it is not
TestFlight is Apple's beta distribution service, run from the TestFlight tab of App Store Connect. You upload a signed build, add it to a group, and the people in that group install it through the free TestFlight app on their own device. Apple is explicit that you do not need to keep track of UDIDs or provision tester profiles. That single line is the practical difference between TestFlight and ad hoc distribution, and it is why most teams stop registering devices by hand.
The counts are fixed, so know them before you promise anyone anything. You can designate up to 100 members of your development team holding the Account Holder, Admin, App Manager, Developer or Marketing role as internal testers. You can invite up to 10,000 external testers. Testers can use the builds you share with them on up to 30 devices, and you can share up to 100 builds and test several at once.
Groups are the unit of control. You can create several and give each one a different build, which is how a rough Friday candidate stays away from the people who only ever see the stable build. It is also how you stop testing for one audience without disturbing another.
TestFlight is not a way onto a phone without an Apple Developer Program membership. It is not a private App Store for customers who will never send feedback, and it is not anywhere to host an app for long. It is a testing window, and the window closes on its own.
The 90 day clock and the review gate
Apple states it plainly: you can test a build for up to 90 days, and your build becomes unavailable for testers after 90 days. Nothing renews it, and there is no setting that buys more time. When a build lapses, the fix is a fresh upload. A beta that has to run a full quarter needs at least one planned replacement in the middle of it.
You can also end testing early. Apple gives you the option to expire a build to stop testing it. It also flags the case teams forget. If you do not expire your build and you then submit it to the App Store, testers who received an invitation can still test that build after the app goes live. A tester filing bugs against a build you thought was dead is usually this.
The review gate is worth reading twice, because Apple describes it in two places and the wording differs. App Store Connect Help says that if you invite external testers, your beta build may require review. It says the first build of your app added to a group is sent to App Review, to check it follows the App Review Guidelines. It then says a review is required only for the first build, and that subsequent builds may not require a full review. The TestFlight page puts it more firmly. To invite external testers you need your first build already approved by App Review for TestFlight, and builds are sent for review automatically once added to a group.
Read together: plan for the first external build to wait. Do not plan a launch date around a later build sailing through, because Apple says only that it may not need a full review. We did not find an Apple page stating that internal testing skips review altogether, so treat that as folklore rather than a rule you can schedule against. TestFlight beta testing is judged against the App Review Guidelines, which means a build that would be rejected on the store can be rejected here.
Apple, TestFlight overview in App Store Connect Help
Try it
How much of the 90 days is left
Apple gives a build 90 days of testing and nothing renews it. Put in how old the current build is and how long you still need testers on it.
78 days of testing left
This build covers the window you asked for. On day 90 it stops being installable and testers need a newer upload.
How a TestFlight invite reaches a person
There are two doors. Email invitations go to specific people you already know: they get a link, install the TestFlight app, and start testing. Public links go in a post, a newsletter or a support reply, and need no contact details in advance. Apple suggests them as a good way to assemble a first group of testers.
A public link can be filtered and switched off. You can set criteria such as device type and OS version, so only testers who fit can enrol. Apple advises disabling the link once you reach your tester limit, so people who try to join learn it is closed rather than hearing nothing. You can see how many people viewed and installed from the link, and how many met the criteria you set.
The invite itself is a small piece of marketing. It carries your beta app description, and apps with an approved version ready for distribution can also show their screenshots and app category in the invite. That is a quiet reason to have app screenshots for app store done before the beta rather than after it. Apple also notes that people who decline can leave feedback telling you why, which is worth reading when a public link converts badly.
Feedback comes back through the same channel. Testers can send it from inside the beta app, and you read it in the TestFlight Feedback section of App Store Connect. Testers on tvOS, or on earlier versions of iOS, send feedback to the email address you gave when you set up the test. That address needs to be one somebody actually watches.
What has to be true before the build gets out
First, the build has to be eligible. Apple requires builds to include application identifiers within the provisioning profiles to be eligible for TestFlight. In plainer words, a mismatched bundle identifier or a profile borrowed from another app fails at the door, usually late in the day.
Second, the export compliance question has to be answered. Apple points you at its cryptography and US export compliance guidance to decide whether your app needs encryption documentation. Leave it unanswered and the build sits in processing while nobody can install anything.
Third, the text has to exist. Your beta app description and beta app review information are required in order to share a beta with external testers. Writing them at the moment you want to ship is how a Friday release becomes a Monday one. Twenty minutes the week before is the whole fix.
None of it has to be manual. The app store connect api exposes builds, beta groups and testers. A pipeline can upload a build, attach it to a group and invite people without anyone opening a browser. Newly covers the upload end of that. It builds the iOS app and sends it to TestFlight through App Store Connect, using your own Apple Developer account, because the app has to belong to you rather than to the tool that made it.
What each way of handing out a build gives you
| Option | Who can install | Apple review gate | How long the build lasts | Needs device IDs |
|---|---|---|---|---|
| TestFlight internal group | Up to 100 App Store Connect users | First build to a group goes to review | 90 days | No |
| TestFlight external group by email | Up to 10,000 testers | First build must be approved | 90 days | No |
| TestFlight public link | Up to 10,000 testers, criteria optional | First build must be approved | 90 days | No |
| Ad hoc build | Registered devices only | None | Until the provisioning profile expires | Yes |
| Run from Xcode over a cable | One device at a time | None | Until the provisioning profile expires | Yes |
Building the loop that runs around it
TestFlight is the delivery step, not the process. The work around it is dull, and it is where small teams lose days. You keep the build number moving. You write what changed so testers know what to look at. You trace a bug back to the build it came from. You remember that in 90 days every one of those builds is gone. None of it is hard. It is just constant.
Off-the-shelf tools stop fitting at the edges. A continuous integration service will build and upload happily, then leave you chasing the people who installed nothing. A spreadsheet of testers works until someone asks which of your forty testers is on the current build. Apple gives you tester metrics in App Store Connect, plus counts for public link views and installs. That covers more of this than most teams realise, so look there before building a dashboard nobody asked for.
Newly is an AI app builder. You describe the app in plain English, it writes a React Native and Expo project you own, runs it on a cloud iPhone while it builds, and uploads iOS builds to TestFlight. Plans start at $25 a month and there is no free plan. Android has no TestFlight at all, and the Deploy tab treats it separately. One press builds, signs and uploads the app to Google Play internal testing. It also produces a standalone release APK you can install on a phone directly. That is the Android equivalent of everything described here.
Questions people ask about iOS TestFlight
It is Apple's beta distribution service, run from the TestFlight tab in App Store Connect. You upload a signed build, put it in a tester group, and those people install it through the free TestFlight app on their own device. Apple states you do not need to collect UDIDs or provision tester profiles, which is what separates it from ad hoc distribution.
Get something worth testing into TestFlight
Describe the app you want, get a real iOS build, and spend your 90 days on feedback instead of on signing and upload problems.
Start building