How Many Updates Should You Ship During the 14-Day Closed Test?

Short answer: ship the initial build, then plan for one to three updates over the 14 days, each one driven by something you learned from testers. As far as we know, Google does not publish a minimum number of updates for the closed test. The requirement is about testers: 12 opted in for 14 days in a row. Updates are optional, so treat them as a way to improve the app, not a box to tick.

Rules and wording in Play Console change, so check Play Console Help for the current requirements before you plan around any of this.

Why not zero updates?

Shipping nothing for two weeks is allowed. But you will be running a test, collecting feedback, and then ignoring it. If testers report a crash on day 3 and your build sits unchanged until day 14, you have wasted most of the test.

Fixing real problems also gives you a good answer when Play Console asks what you learned and changed. Our post on turning tester feedback into an update goes deeper on that side of it.

Why not an update every day?

Daily releases look busy but cause problems:

• Testers chase a moving target. Each tester uses the app for about 20 minutes a day. If the build changes constantly, they spend that time re-checking old flows instead of finding new issues.
• Feedback gets muddy. When five things change at once, you can't tell which change caused a new bug.
• You may add regressions. Rushed fixes tend to break something nearby.
• Review delays are unpredictable. Updates to a testing track can take time to become available, and how long varies. A fast cadence only works if you can count on fast availability, and you can't.

A simple cadence that works for most small apps

Here is a plan you can adapt. The days are a guide, not a rule.

1. Day 0: the baseline build. Upload a build that is stable enough to use for 20 minutes without hitting a wall. See the pre-launch checklist if you haven't gone through it.
2. Days 1–3: watch, don't touch. Let testers opt in and run the app. Read the first feedback and note crashes and confusing screens. Don't ship yet unless something is badly broken, such as a crash on launch.
3. Around day 4–6: update one. Fix the most common crash or blocker and the one or two usability complaints that came up more than once.
4. Around day 8–10: update two. Address the next round of feedback. This is also a good time for a small improvement a tester asked for, if it is low risk.
5. Day 11–12: optional final polish. Only if there is a clear bug worth fixing. Otherwise, leave the build alone.
6. Last day or two: hold. Use the time to review feedback and prepare your production access answers.

That gives you two or three updates, spaced far enough apart for testers to try each one properly.

What makes an update worth shipping

Ask one question before you upload: can I describe this update as a response to something a tester told me or something I observed? If yes, ship it. If it's a pure refactor or a feature nobody asked for, consider holding it until after the test.

Good candidates:

• Crashes or freezes reported by more than one tester
• Broken flows, such as a button that does nothing on certain screen sizes
• Confusing onboarding or unclear wording
• Layout problems on particular devices
• Performance issues like slow startup

Poor candidates:

• A redesign halfway through the test
• Large new features with no time to test them
• Changes made only so the version number goes up

Keep a short changelog

For each update, write down what changed and which piece of feedback prompted it. Two lines is enough. You'll thank yourself when you answer the production access questions, and you can share the notes with testers so they know what to re-check.

Mechanics to get right on every update

• Increase the version code. Play will reject an upload that doesn't have a higher version code than previous ones.
• Use the same closed track. Releasing to a different track can confuse testers and make it harder to see who is testing what.
• Don't remove testers from your list. The 14-day count depends on testers staying opted in. Our post on why the counter resets covers what to avoid.
• Sign consistently. Use the same app signing setup as before.
• Check availability before you ask testers to retest. Confirm the new version actually shows up on a tester device, then tell testers to update.

Details on how updates interact with the testing period can change, so confirm in Play Console Help rather than relying on any blog post, including this one.

Timing around tester activity

Testers do their best work when they have a few days with a stable build. If you push an update on day 2, you've reset their familiarity with the app before they've learned it. Waiting until you have a handful of feedback reports means each update fixes several things at once.

If you use TesterMob, testers are on their own Android phones and send written feedback, so you'll often have real notes to work from by the time you plan your first update. The optional Android SDK (an .aar file) shows daily tester activity in your dashboard. That is useful for a sanity check: if activity drops after an update, something about the new build may be getting in the way. It's a signal to look at, not proof. You can read how it works on the developer page or the FAQ.

Should you update on the final days?

Avoid it unless you must. A last-minute upload leaves no time to find out whether you broke something, and any availability delay eats into the days you have left. If a serious bug turns up late, fix it, but keep the change as small as you can.

A quick rule of thumb

• Small, simple app: one or two updates.
• Larger app with many flows: two or three updates.
• Early crashes that block use: ship a fix right away, then return to the normal rhythm.
• Quiet feedback: don't invent updates. Ask testers specific questions instead.

The takeaway

There is no right number, only a right reason. Ship a stable build, give testers a few days, fix what they actually find, and keep the last stretch calm. Two or three well-explained updates are better than ten rushed ones.

No approach can guarantee Google will approve production access, and neither can we. What you can control is running a clean test and documenting what you learned. If you need testers to get started, see the pricing page: it's $9.99 per app, paid once in USDT.