Can you update your app during closed testing? The 14 days keep going — how and how often to update

1. Yes, you can update — the 14 days keep going

Uploading a new version during closed testing doesn’t restart the 14 days. The Play Console Help Center article describes the requirement only as “at least 12 testers continuously opted in for 14 days,” and doesn’t set any condition on the number of versions or whether you update. Uploading a new version to the same track doesn’t change testers’ opt-in status.

What breaks the 14 days isn’t updating — it’s losing testers: a tester opts out or uninstalls the app, gets removed from the tester list, or you move to a newly created track. The detailed counting rules are in when do the 14 days start?

2. Why updating is better

When you apply for production access after the 14 days, the last part of the questionnaire asks how you changed your app based on the results of your closed test, and why you believe it’s ready for release. If you had only one version for the whole test, you have nothing to write here.

On the other hand, if you have a record of the versions you shipped during the test and what you fixed in each, that becomes the basis for your answer. Writing version numbers together with what changed — “1.0.2 cut first-screen loading time, and 1.0.3 fixed a login error testers reported” — gives the reviewer something they can verify. Examples for each question are in production access questionnaire examples, and the problems with having only one version are covered in 7 reasons requests get rejected.

3. How to upload an update in Play Console

1. Increase your app’s version code (versionCode) to a higher number than the previous version and build a new App Bundle (.aab). A version code can’t be reused once it’s been used.
2. In the left menu, go to Test and release → Testing → Closed testing, and click Manage track on the track your testers are currently on.
3. On the Releases tab, create a new release, upload the App Bundle, describe what changed in the release notes, and save.
4. Send your changes for review from Publishing overview in the left menu. If managed publishing is on, you have to publish the changes yourself after review before they reach testers.
5. Once review is done, the update appears in testers' Play Store. Devices with auto-update on will get it on their own; otherwise testers update manually.

4. How often, and what to ship

There’s no set number. In practice, every 3–4 days — two or three updates over the 14 days — leaves you plenty of history for the questionnaire. You don’t need to build big new features; small changes are fine as long as they come from what you saw in testing.

• Fixes for problems or errors testers told you about
• Fixes for issues that only happened on certain devices or OS versions
• Faster first-screen loading (if the first launch is slow, testers use the app less)
• Cleaning up wording or layouts that confused testers

If you write one line in the release notes about what changed for each version, that list becomes your answer when you fill out the questionnaire later. If you make big changes right before applying, testers won’t have time to try that version, so ship major changes in the early-to-middle part of the test.

5. How updates can break your test

Updating itself doesn’t break the 14 days, but there are mistakes during an update that can.

• Uploading to a newly created track. If you switch tracks, the opt-in time built up so far doesn’t carry over. Upload updates to your current track.
• Uploading to the internal testing track. It won’t reach closed testers, and only closed testing counts anyway (internal vs. closed vs. open testing).
• Cleaning up the tester list while you’re at it. Accounts removed from the list stop counting immediately. During the test, only add — never remove.
• Shipping a version that breaks on first launch. Testers tend to uninstall an app that closes as soon as they open it, and once they do, they stop counting. Check installation and first launch on your own device before you upload.

6. When testers don't see the update

• Check whether it’s still listed under Changes in review in Publishing overview. It only reaches testers once review is done.
• If managed publishing is on, check that you published the changes yourself after review.
• Check that you uploaded the version to the same track your testers are on.
• Right after publishing, the Play Store can take a while to notice the update. Testers can open the app's Play Store page and update manually.

With DUIRE, our test devices check for new versions every day. Just upload a new version to Play Console and the devices pick it up and install it, keeping a history of which version was installed on each device and when. That history goes into the final report and backs up your questionnaire answers.