How many beta testers does a mobile app need? (and where to get them)
How many beta testers a mobile app needs, by goal: store requirements, device coverage, usability feedback and crash detection, plus where to find testers. By betatest.ing team · October 14, 2026 · 7 min read.
Key takeaways
- The number depends on the goal: store requirements, device coverage, usability feedback or crash detection each imply a different count.
- Personal Google Play accounts created after 13 November 2023 must run a closed test with a minimum tester count opted in for 14 days; recruit extra testers as a margin.
- Five to eight engaged testers per round is enough for usability feedback; run two or three rounds instead of one big one.
- Crash detection benefits from volume: use open testing and automated device-matrix runs for the rare paths.
- Twenty to thirty real people across the whole beta covers most indie apps; expect a third of invitees never to install.
In this article
- Start from the platform limits
- Goal 1: meet the store requirement
- Goal 2: cover devices and OS versions
- Goal 3: get usability feedback you can act on
- Goal 4: catch crashes and rare bugs
- Putting it together
- Where mobile beta testers actually come from
- Keeping the testers you found
- Related guides
- How betatest.ing fits
"How many beta testers do I need?" is the most common question we hear from mobile developers, and the honest answer is that the number depends on what you want the beta to tell you. A beta that exists to satisfy Google Play's closed-testing rule needs a different count than one meant to find crashes across Android's device zoo, which is different again from one meant to tell you whether onboarding makes sense. This post works through each goal, gives a defensible range, and then covers where mobile testers actually come from.
Start from the platform limits
The ceilings are fixed by the stores, so know them first.
- TestFlight (iOS): up to 100 internal testers from your App Store Connect team and up to 10,000 external testers, per Apple's TestFlight documentation.
- Google Play internal testing: up to 100 testers.
- Google Play closed testing: list-based, through email lists or Google Groups, with multiple tracks allowed.
- Google Play open testing: anyone from the store listing, with an optional cap you set.
Nobody indie-sized is constrained by the 10,000 ceiling. The constraint is the floor, and on Android there is a hard one.
Goal 1: meet the store requirement
If you have a personal Google Play developer account created after 13 November 2023, you must run a closed test with a minimum number of testers continuously opted in for at least 14 days before you can apply for production access. The requirement is described in Play Console Help; the tester count has been revised since the policy launched, so read the number in your own console.
Whatever the number is, recruit roughly half again as many. "Continuously opted in" means a tester who installs, gets bored and uninstalls on day nine can set you back. Spare testers are cheap insurance against a two-week delay.
Apple has no minimum. You can ship to the App Store having tested with nobody but yourself, which is exactly why so many iOS apps get rejected on the first submission.
Goal 2: cover devices and OS versions
Mobile bugs cluster by device class, not by user count. Twenty testers on recent Pixels tell you less than eight testers spread across a Pixel, a Samsung, a Xiaomi, a tablet, and three Android versions. For iOS, the spread is narrower: small phone, large phone, iPad if you support it, and the oldest and newest OS you target.
A practical way to count: list the device and OS combinations you need to see, then aim for two testers per combination so that a single flaky tester does not leave a hole. For a typical indie Android app that is five or six combinations, so ten to twelve testers; for iOS, three or four combinations, so six to eight. If you do not have testers with the right phones, this is also where emulators, simulators and hosted real devices fill in, which we come back to below.
Goal 3: get usability feedback you can act on
Usability research has long argued that a handful of participants per round finds most of the problems visible in that round, and that it is better to run several small rounds than one large one. The reasoning holds for beta onboarding and core flows: after the fifth or sixth person stumbles on the same screen, the seventh is not telling you anything new. Fix it, ship a build, and watch five fresh people.
So for the qualitative part of a mobile beta: five to eight engaged testers per round, with two or three rounds across the beta. Engaged is the operative word. One tester who records a screen and talks through it is worth ten who install and never open the app again.
Goal 4: catch crashes and rare bugs
Crashes are a numbers game. The more sessions on more devices, the more of the rare paths you exercise. This is the one goal where more testers is simply better, and where open testing earns its place. If you can get a few hundred people on an open track, Android vitals and your crash reporter will surface the device-specific crashes that no deliberate test plan would have found.
If you cannot get hundreds, compensate with session volume rather than tester count: ask a smaller group to use the app daily for two weeks, and run automated sessions on a device matrix for every build so that at least the deterministic crashes are found by machines.
Putting it together
For an indie mobile app, a defensible plan looks like this:
| Phase | Who | How many | Purpose |
|---|---|---|---|
| Internal | Team and friends | 5–10 | Smoke, obvious bugs, build pipeline |
| Closed round 1 | Target users, chosen for device spread | 12–20 | Store requirement on Android, device coverage, first usability pass |
| Closed round 2 | Same group plus replacements | 12–20 | Verify fixes, second usability pass |
| Open (optional) | Anyone | As many as you can get | Crash and rare-bug detection |
Twenty to thirty real people across the beta is enough for most apps. If that number feels high, remember that at least a third of invited testers never install, and another third stop after the first session. Our how many beta testers guide goes deeper on the drop-off math for web and mobile.
Where mobile beta testers actually come from
Finding mobile testers is harder than finding web testers because installing a TestFlight or Play build is a commitment. These channels work, roughly in order of effort.
Your own waitlist or audience
The best testers are people who already wanted the app. A landing page with a waitlist, a newsletter, or the user base of your previous product. Ask for device model and OS version on the signup form so you can choose for coverage.
Communities where your users already are
Subreddits, Discord servers, Slack groups and forums specific to the problem your app solves. Read the rules first; many have a weekly thread for feedback requests. A short, honest post that says what the app does, what you need tested, how long it takes and what testers get in return performs better than a polished pitch. The beta tester recruitment generator drafts one.
Beta-specific communities
There are communities and directories built around testing pre-release apps. Quality varies, and some attract people who install for a reward and never return, which is exactly what you do not want for a 14-day opt-in requirement. Use them for volume on open testing, not for your core closed group.
Paid testers and testing marketplaces
Paying people to test is legitimate and often the fastest way to fill device gaps, for example "I need three testers on Samsung phones running Android 13". Be clear about the task, pay promptly, and do not ask them to leave store reviews, which both stores prohibit as incentivized reviews.
Friends and family, with caveats
Fine for the internal round. Poor for usability feedback, because they know you and know too much about the app. Also poor for the Android closed-testing requirement if they are not representative of your users, because Google asks about your test when you apply for production access.
Automation for device coverage
When the gap is "I need to see this on devices I do not have", an AI beta tester running on emulators, simulators and hosted real devices closes it without recruiting anyone. It does not replace the human testers who give you honest reactions and real-world conditions, but it means your human count can be driven by feedback and store requirements rather than by hardware you happen to lack. The how to find beta testers guide has more channels, including ones that work when you have no audience at all.
Keeping the testers you found
Recruiting is half the job. To keep testers opted in for the whole beta:
- Send a short welcome with one clear first task.
- Reply to every piece of feedback, even with one line.
- Ship visible fixes and say what changed in the build notes.
- Set an end date and keep it; open-ended betas lose people.
- Thank them in a way that is specific: a credit in the app, early access, a discount.
Related guides
How betatest.ing fits
betatest.ing is an AI beta tester for websites, web apps and Android and iOS apps. For mobile, it installs your build on emulators, simulators and real devices and works through goals you set, filing bugs with steps, severity, annotated screenshots and recordings, and producing a scored report after each run. Use it to cover the device matrix and the regression grind on every build, and spend your human testers on usability feedback and the store requirements that only real people can satisfy.
Start for $1 and get device coverage before your first human tester installs.
Related guides
Each ends with a test task you can send to your AI beta tester.
Keep reading
- AI mobile app testing: what an AI beta tester can and can't do on a phone — An AI beta tester on a phone sees the accessibility tree and the screen, taps, types, reads crash logs and records everything. It cannot be a real camera, notification or wallet. Here is the line.
- Testing in-app purchases and subscriptions in sandbox without losing money — StoreKit configuration files, App Store sandbox accounts, Play license testers and RevenueCat sandbox mode each cover a different layer. What to test at each one, including restore, renewal and cancellation.
- Beta testing a React Native or Flutter app: platform bugs you only find on a device — Cross-platform frameworks share your logic, not your bugs. The failures that slip past a simulator and show up on a tester's phone: keyboards, safe areas, back gestures, font scaling and native modules.