Play's closed testing requirement
This is a lead time, not a review step, and it is the one that most often moves a launch date.
Certain new personal developer accounts must run a closed test with a minimum number of opted-in testers for a continuous period before applying for production access. Organisation accounts and established accounts have not been subject to it in the same way.
Take the current tester count and duration from Play Console rather than from any article, including this one. Both have been revised since the policy was introduced, and a stale number here would be worse than none.
The part that catches people is not the number. It is that testers must genuinely opt in, and the clock only runs while enough of them are actually enrolled. Adding email addresses to a list does nothing. Developers commonly discover this weeks in, having assumed the clock started when they created the list.
What it actually requires
A closed test track in Play Console with your app on it.
Testers who have opted in. Each person has to accept the invitation and install from the test link. A list of addresses is not a list of testers.
Continuously, for the required period. Testers dropping out mid-way is the failure mode nobody plans for, because a tester who uninstalls stops counting.
Then an application for production access, which is reviewed.
Planning around it
Treat it as a lead time before submission, not a step during it. If you are building toward a date, the closed test has to start weeks before the date, and it cannot be compressed by working harder.
Recruit more testers than the minimum. People uninstall, change phones, and lose interest. Running at the exact minimum means one dropout resets your position.
Recruit people who will actually install. Friends who say yes and never open the link are the most common reason a test that looks staffed is not. Ask directly and confirm each install.
Use the closed test for its actual purpose while it runs. You have a captive group of real devices for several weeks. Use it to find the crashes and the device-specific problems that would otherwise turn up as one-star reviews.
Check whether an organisation account changes your position before you start, if you have a legal entity. The requirement has applied to personal accounts, and this is worth confirming for your circumstances rather than assuming either way.
What it means alongside the App Store
The two platforms have different shapes and the difference is worth planning for.
Apple is a human review measured in days, with the possibility of several round trips. Your risk is the number of iterations, which is what pre-submission checking reduces. What a rejection actually costs.
Play for a new personal account has a fixed multi-week floor that no amount of preparation removes, followed by automated policy checks that can block an upload outright — target API level being the clearest example. Play target API level.
So a simultaneous launch is not two parallel submission efforts. It is one process with a hard floor and one with a variable ceiling, and if you have not started the Play clock, the iOS date is the one that will slip to meet it.
While the clock runs, do the rest
The closed-test period is dead time you can spend on the things that block a Play release anyway:
- Data safety declaration, derived from what your SDKs actually collect rather than from memory. How to derive it.
- Target API level, raised early rather than at the deadline, so you find the library that has not caught up while you still have weeks.
- Permissions declaration for anything sensitive, with the demonstration video recorded.
- Account and data deletion, including the web-accessible route Play expects.
- The merged manifest, read properly, so you know which permissions your libraries added. Auditing what config plugins added.
Every one of those is findable in the repository before you build, which is what shipcheck scans for locally, inside the Claude Code session you already have open. It does not shorten the closed test. It makes sure the weeks are not wasted. What it checks.
Google revises this policy, including the tester count and the duration. Every claim here links to Google's own documentation and deliberately avoids stating a number that would go stale. Read the requirement as it appears in your own Play Console, since it is surfaced against your specific account.
Questions and answers
What is Google Play's closed testing requirement?
A requirement that certain new personal developer accounts run a closed test with a minimum number of opted-in testers for a continuous period before they can apply for production access. Check Play Console for the current tester count and duration, as both have changed since the policy was introduced.
How many testers does Google Play require?
The number and the duration are set by Google and have been revised since introduction, so take them from Play Console rather than from any article. What has been stable is the shape - a minimum number of testers who actually opt in, sustained continuously rather than counted once.
Does the closed testing requirement apply to everyone?
No. It has applied to personal developer accounts created after a cut-off date rather than to organisation accounts or to established ones. Check your own account status in Play Console; the requirement is surfaced there.
What counts as an active tester?
Testers must actually opt in to the test, not merely be listed. Adding email addresses to a list does nothing on its own, which is the single most common way developers discover they have not met the requirement until the clock has already been running.
How does this affect a launch date?
It puts a fixed multi-week floor under any Play launch from a new personal account, and the clock only starts once enough testers have genuinely opted in. Plan it as a lead time before submission rather than as a step during it.
shipcheck. “Play's closed testing requirement.” Baker Ventures LLC, September 6, 2026. https://shipcheck.bakerventuresstudio.com/rejections/play-closed-testing-requirement/