Production Access Approved: What Happens Next on Google Play

Short answer: nothing gets published automatically. Approval of production access only unlocks the ability to create a production release. Your app stays unpublished until you submit that release and it passes Google's review.

Here is what to expect, in order, and what to do in the first couple of weeks. Google Play processes and screens change over time, so check Play Console Help for the current details.

What approval actually changes

Before approval, the Production section of your app is locked. After approval, you can create a production release. That is the whole change.

Your closed testing track still exists and still works.
Your store listing, content rating, Data safety form and target audience settings are not changed.
The 12-testers-for-14-days requirement was the gate you just passed. You do not need to keep the same testers opted in for the production release itself.

One caution: the testing requirement applies to new personal developer accounts, and the details have changed before. If you plan to publish more apps from the same account, read the current rules in Play Console Help rather than assuming how they apply.

Step 1: Decide which build to release

You have two common options:

Promote the build from your closed test. This ships exactly what your testers used. It is the lowest-risk choice if the last closed test build was stable.
Upload a new build. This makes sense if you fixed bugs from tester feedback after the last closed test release. Make sure the version code is higher than any build you have uploaded before. The Android versioning docs explain how versionCode works.

Either way, you still need a signed Android App Bundle, as in every earlier release. If you have not touched your signing setup since the closed test, it should carry over unchanged.

Step 2: Check your release settings before you submit

Do a final pass in Play Console before you hit the button. It is easier to fix a mistake now than after the app is live.

Countries and regions. Production defaults may not match what you set for testing. Choose where the app should be available.
Release notes. Write real notes for the first release. Short and honest beats a copy of the app description.
Store listing. Check screenshots, the short description and the feature graphic. Confirm nothing is still a placeholder from testing.
App content declarations. Content rating, ads, Data safety, and anything else Play Console flags should be complete and accurate. Your declarations should match what the app does.
Managed publishing. If you want to control the exact moment the app goes live after review, look at the managed publishing option in Play Console Help.

Step 3: Choose a full or staged rollout

For a first release, a staged rollout is worth considering. You release to a percentage of users, watch what happens, and then increase the percentage. If something breaks, you can halt the rollout instead of exposing everyone.

The catch is that a brand-new app has no existing users, so the benefit is smaller than for an update to an established app. Still, a small initial percentage gives you a window to spot a crash that your testers never hit. Check Play Console Help for how staged rollouts behave for new apps.

Step 4: Wait for review

After you submit, the release goes through Google's review. Review times vary, and Google does not guarantee a timeframe, so do not schedule a launch announcement for a specific hour.

During this time:

Do not keep uploading new builds unless you need to. Each new submission can affect what is in review.
Watch your developer email and the Policy status or Publishing overview pages in Play Console.
If the release is rejected, read the stated reason carefully and fix that specific issue before resubmitting.

Approval of production access is not a guarantee that the production release will pass review. They are separate steps.

Step 5: The first week after going live

Once the app is live, the work shifts from "get approved" to "keep it healthy."

Watch stability

Open Android vitals and the crashes and ANRs reports. With few installs, the numbers will be small and noisy, so look at individual stack traces instead of percentages. A single crash on a popular device model is worth fixing quickly.

Read and answer reviews

Early reviews shape how the listing looks. Replying politely and specifically, especially to bug reports, shows people the app is maintained. Do not ask for reviews in a way that pressures users, and check Google Play's policies on review solicitation.

Test on a real device from the store

Install the app from the Play Store on your own phone, signed out of your developer testing setup if possible. Confirm that sign-in, purchases, ads and permission prompts all work in the production build, not just the debug build you used in development.

Plan your first update

Most apps need a quick follow-up after launch. Collect the bugs you find yourself, the issues from reviews and the crash reports, and group them into one update. Shipping small, frequent fixes is fine, but each update should still be tested before it goes to everyone.

Keep your closed testing track

Do not delete the closed track just because production is open. It is useful as a safe place to try a risky update before it reaches real users:

Upload the new build to the closed track.
Install it on a few devices and run through your key flows.
Promote it to production only when it behaves.

If you want fresh eyes on a major update, you can bring in testers again. TesterMob's testers use their own Android phones and send written feedback; see the developer page for how it works and pricing for the one-time $9.99 per app fee. It is optional, and it does not replace your own testing or guarantee that Google approves anything.

Common mistakes right after approval

Assuming the app is live. It is not until you create and submit a production release and it passes review.
Shipping an untested last-minute change. A "tiny fix" made after the closed test is the most common way to introduce a launch-day crash.
Ignoring declarations. If the app changed since you filled in Data safety or the content rating, update them before release.
Skipping monitoring. With a small user base, problems hide. Check vitals and reviews on a schedule, for example daily for the first week.
Telling testers to uninstall immediately. There is no need to rush that. Testers who stay installed can still give you useful feedback on the production build.

A simple post-approval checklist

Choose the build: promote the tested one or upload a newer one with a higher version code.
Review countries, release notes, store listing and app content declarations.
Decide on a staged rollout and on managed publishing.
Submit and wait for review without piling on extra uploads.
After launch, check Android vitals and reviews every day for the first week.
Collect issues into your first update and test it on the closed track first.

If something in this flow does not match what you see in your console, trust Play Console Help over any blog post, including this one. For questions about testing your app on TesterMob, see the FAQ.