A hundred testers is a plumbing problem. Every track has a ceiling and your build has ninety days.
This page is not about finding a hundred people. It is about getting a working build onto their phones and keeping it there, which is a separate job with published rules and two numbers that decide your schedule. Apple caps a TestFlight internal group at 100 App Store Connect users with access to your content, and an external group at 10,000 people. It gives any build 90 days and then takes it away from testers. Google caps an internal test at 100 testers per app, publishes list limits for closed testing, and leaves open testing unlimited. Every figure here was read from Apple's and Google's own help pages on 16 October 2026. If you are still counting the bill, start with what it costs to publish an app.
Recruiting the hundred is covered separately in our honest answer to how you get your first app users. What follows is the part that happens after they say yes: how many slots each track gives you, how long a build survives, why a new test link appears to be broken on its first day, and when the track you are on runs out and forces you onto the next one.
Start hereThe short version
Pick the track by its ceiling, then plan around the clock.
A hundred people fits in the quietest track on both stores, and that is the whole reason the first hundred feel different from the second hundred. A TestFlight internal group and a Google Play internal test both stop at a hundred. Cross that line on iOS and you are in an external group, which brings a review step. Cross it on Android and you are on a closed track, addressed by email lists.
The clock is the part nobody plans for. Apple gives a build ninety days of testability and then it stops working for your testers, which turns a six month test into a release schedule rather than an upload. Google publishes no equivalent expiry, but it does publish delays at the start: several hours for a brand new test link, and up to forty eight hours of placeholder listing information on a first upload. Plan the ceiling once. Plan the clock every quarter.
How many slots does each track actually give you?
On iOS there are two ceilings and they are not interchangeable. Apple's App Store Connect Help says you can add external testers, up to 10,000 people, and internal testers, up to 100 App Store Connect users with access to your content. That second condition is the one that bites. An internal tester is not somebody you happen to trust. They hold a seat in your App Store Connect account with access to the content, so a hundred customers cannot be internal testers however well you know them. Apple adds that Managed Apple Accounts created in reserved domains cannot be used to test builds, which rules out some work addresses before you have even sent the invitation.
So for most people a hundred real testers means an external group, and the 10,000 figure is not the practical limit either. Apple notes that setting specific criteria for your public link invitations can limit the number of external testers who can test your app. A link with conditions attached is not a link for ten thousand, and that is by design rather than a fault.
Google publishes a number for each of its three tracks. An internal test can have up to 100 testers per app, described as a way to quickly distribute your app for initial quality assurance checks. Closed testing comes with three figures rather than one: up to 200 lists, up to 2,000 users a list, and up to 50 lists per track. Additional closed tracks can be addressed with a Google Group instead, and Google states there are no size limits to these groups. Open testing is unlimited by default, and if you choose a limited number it has to be at least 1,000, which means there is no such thing as a small open test.
Read those together and the shape of the problem is clear. The hundred is not an arbitrary target somebody in marketing invented. It is the published capacity of the quietest route on both stores, and the moment you want the hundred and first person you are doing a different kind of work: review on one store, list management on the other.
Work it out
Which track holds your group, and for how long
Published ceilings only. The arithmetic is the stores' numbers, not a guess about your app.
1 iOS upload minimum
Apple gives a build 90 days and then it becomes unavailable to testers. Over 56 days that is 1 build at the very least, before any bug fix forces another.
On iOS
A TestFlight internal group holds this, but only if every one of them is an App Store Connect user with access to your content.
On Android
A Play internal test holds up to 100 testers per app, which covers this.
Your account has to run a closed test with at least 12 testers opted in continuously for 14 days before you can apply for production access, so the internal track cannot be your only one.
Ceilings read from Apple and Google help pages on 16 October 2026. Neither page carries its own last-updated date, so check before you commit a schedule to them.
How long does a build stay testable?
Ninety days on TestFlight, and Apple says it twice on the same page so there is no reading around it. You can test a build for up to 90 days. Your build becomes unavailable for testers after 90 days. That is one sentence with real consequences, because the ninety days belong to the build and not to the tester. Invite a group in March, go quiet while you work on something else, and in June those hundred people have an app on their phone that no longer opens. Nothing notified them. Nothing notified you.
The expiry runs the other way too, and this one surprises people more. Apple says that if you do not expire your build and you submit it to the App Store, testers who received an invitation will still be able to test that build after it goes live. So an old beta can keep running next to your shipped version, which is exactly the configuration that produces a bug report you cannot reproduce. You can expire a build yourself to stop testing it, and the day you ship a public version is the day to do it.
Google publishes no matching expiry for its testing tracks. That is not a promise that a build lasts forever, it is an absence, and the honest way to treat an absence is to not build a plan on it. What Google does publish is the speed at the other end: a new app bundle becomes available to testers within minutes, and once testers have installed the app it updates itself to the test version within a few minutes. Android gives you a faster loop and no deadline. iOS gives you a deadline you can schedule around.
In practice that means you should decide your upload cadence before you invite anybody. A twelve week test is one build if nothing goes wrong and nothing ever does not go wrong. A six month test is three uploads minimum on iOS, each one a fresh build somebody has to prepare, and each one a reason to write a note to a hundred people explaining what changed. Treat it as a small release train from the first week and it stays manageable.
Apple, App Store Connect Help, overview of TestFlight, read 16 October 2026
Why does the link look broken on the first day?
Because on Google Play the first publication of any test type is slow in a way nothing warns you about while you are doing it. Google says the test link can take several hours to become available to testers. Several hours is long enough for ten people to tell you the link is dead, for you to delete and recreate the release, and for the whole thing to start again. The fix is to publish the first test a day before you send the invitations and say nothing until you have installed it yourself.
The second confusing one is the listing. Google says that for a first upload it may display temporary name and store listing information for up to 48 hours. Your testers see a placeholder title and assume they have the wrong app. It resolves itself, but only if you know it is going to, so put that sentence in the invitation.
One more thing on the internal track is worth reading carefully. Google says internal tests might not be subject to standard Play policy or security reviews. That is convenient while you are moving quickly and it is a trap if you read it as approval. A build a hundred internal testers have been happily using tells you nothing about what a production review will accept, so the first time you ask for a public listing is a genuinely new event. On the Apple side the equivalent moment comes earlier, at the external group, and if the answer is no then appealing a rejection is the path rather than another upload.
Payments are the last one, and it is specific. Google states that purchases made in apps on the internal testing track, or in the draft stage, are subject to spend limits. So a hundred internal testers cannot prove that anybody will pay, however many of them tap buy. Keep the questions separate and settle app monetisation on a public track once the app itself is not the variable.
Google Play Console Help, set up an open, closed or internal test, read 16 October 2026
When are you forced off the track you are on?
Three things push you off a track, and only one of them is running out of slots. The first is the ceiling: the hundred and first iOS tester has to be external, and the two thousand and first Android tester needs a second email list. The second is review. Apple says that if you invite external testers your beta build may require review, and that when you add the first build of your app to a group it is sent to App Review to make sure it follows the App Review Guidelines. A review is required only for the first build, subsequent builds may not require a full review, and testing can begin once a build is approved. That is the first hard date in the project and it sits before anybody has installed anything.
The third is an account rule rather than an app one. Play Console Help says developers with personal accounts created after 13 November 2023 must meet specific testing requirements, and the requirements article sets the bar at a closed test with a minimum of 12 testers opted in continuously for at least 14 days before you can apply for production access. For this page the point is narrow and structural: it names a closed test, so a hundred people on the internal track does not satisfy it, and you will be running two tracks whether you planned to or not. Google does allow that, up to a point. You can run multiple closed tests and one open test at the same time.
Because that rule attaches to the account rather than the app, it is worth settling which account owns the listing before you start any clock. A hundred testers, a closed track and fourteen days of history all live under one developer account, and moving the app later means transferring an app to another account, which is its own piece of work with its own conditions.
A sequence that works: an internal test on both stores from the first week, kept running permanently as your own smoke test. A closed track on Android and an external group on iOS as soon as real people outside the company are involved, so the review step and the fourteen day clock are both behind you early. Then an open test only when the listing is genuinely ready to be seen, because on that track the smallest limit Google will accept is a thousand people.
Google Play Console Help, set up an open, closed or internal test, read 16 October 2026
The five tracks that can hold a hundred people
| Track | Published ceiling | Who it will take | Build expiry | Review before testers get it |
|---|---|---|---|---|
| TestFlight, internal group | 100 App Store Connect users | Only people with a seat in your account and access to the content | 90 days a build | Not stated |
| TestFlight, external group | 10,000 people | Anyone, by email invitation or a public link | 90 days a build | Yes |
| Google Play, internal test | 100 testers an app | Any email address, on a list you create | None published | Not stated |
| Google Play, closed test | 2,000 a list, 50 lists a track | Any email address, or a Google Group with no stated size limit | None published | Not stated |
| Google Play, open test | Unlimited, or a limit of at least 1,000 | Anyone who finds the listing or the link | None published | Not stated |
Figures read from Apple and Google help pages on 16 October 2026. Not stated means the store does not publish an answer, which is not the same as no.
Where this lands if a builder generated your app
The ninety day clock is the part a tool can genuinely help with, because the answer to it is simply uploading again. Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project you own, with two way GitHub sync so a developer can work on it next to you. For distribution it uploads iOS builds to TestFlight, publishes to Google Play internal testing, and builds a standalone Android APK you can hand to someone directly. It is $25 a month, with no free tier.
The honest limit is on the iOS submission step. Newly does not submit to the App Store on your behalf, because App Store Review Guideline 4.2.6 rejects apps created from a commercialized template or app generation service unless they are submitted directly by the provider of the app's content. You are the provider of your own content, so you press submit. Internal TestFlight testing does not require that step, which is why a hundred testers can be looking at the app long before a store review is involved.
Nothing about the store rules changes because an agent wrote the code. A hundred internal slots are still a hundred, the ninety days still run on schedule, and the test link on a first Android publication still takes several hours. What a builder changes is how cheap the next upload is, and when a deadline is measured in builds rather than in features, that is the number that decides whether your hundred testers still have a working app in month four.
Questions people ask about testing tracks and tester limits
Two different ceilings, for two different kinds of person. Apple's App Store Connect Help says you can add external testers, up to 10,000 people, and internal testers, up to 100 App Store Connect users with access to your content. The internal cap is the one people trip over, because an internal tester is not simply someone you trust. They need a seat in your App Store Connect account and access to the content, so inviting a hundred customers internally is not an option. Apple also notes that Managed Apple Accounts created in reserved domains cannot be used to test builds, which quietly rules out some corporate addresses. Read 16 October 2026.
Set the tracks up before you need them
Publish an internal test on both stores this week, install it yourself, and find out how long your own build pipeline takes before a hundred people are waiting on it. Then put the ninety day date in a calendar.
Start building