To publish an app on Google Play you pay a one-time fee, verify who you are, declare what the app does with data, and push a signed app bundle through Play Console’s testing tracks to production. None of it is hard. What surprises teams is the order: a new personal account cannot go straight to production, organisation accounts wait on a D-U-N-S Number, and staged rollout, the safety net most people count on, is not available for a first release.
This guide walks through the full process as we run it for clients, with the timings that decide your launch date. If you would rather have the Play Console work done for you inside your own account, see our app store submission services. For the Apple side, the matching guide on how to publish an app on the App Store follows the same structure.
Personal or organisation account: what each one needs
Google offers two account types. The rules below are from Google’s pages on registering a Play developer account and on organisation account verification.
| Personal account | Organisation account | |
|---|---|---|
| Registration fee | US$25, one time | US$25, one time |
| Payment | Credit card in your legal name; prepaid cards not accepted | Same; fee not refunded if verification details are invalid |
| Identity checks | Government ID may be requested; device verification through the Play Console mobile app | D-U-N-S Number required; contact email and phone verified by one-time password |
| Before production | Closed test with at least 12 opted-in testers for 14 consecutive days (accounts created after 13 Nov 2023) | Legal name and address verified before publishing |
| Ongoing risk | Account tied to one person | Account can be restricted if name or address stops matching the D&B profile |
| Best for | Hobby projects and solo developers | Any business app, and every client app we publish |
The closed-testing rule applies to new personal accounts. Organisation accounts are not subject to it, which is one more reason a business should register as an organisation.
Timings that decide your launch date
Play review itself is rarely the long pole. The waiting happens before you can submit at all, and most of it runs on calendars you don’t control.
- D-U-N-S Number: free, nine digits, and an application can take up to 30 days. If your company doesn’t have one, apply the week you decide to build.
- Payments profile verification: can take up to 5 days, according to Google.
- Closed test for new personal accounts: at least 14 consecutive days with 12 or more opted-in testers, then an application for production access.
- Data safety and policy declarations: an afternoon if you have an SDK inventory, a week if you have to reconstruct one.
We schedule account setup in the first sprint of a build, so these clocks run while features are being written. A team that opens Play Console in the final fortnight is almost certain to miss its date.
How to publish an app on Google Play in eight steps
Steps 1 to 3 belong in the first sprint of the project. Steps 4 onwards run in parallel with the last weeks of development.
Create the developer account and pay the fee
Register with a Google account owned by the business, not a developer’s personal Gmail. Choose Organisation for a company app, enter the D-U-N-S Number, and pay the US$25 fee with a card in the company’s or account holder’s legal name.
Complete verification
Verify the contact email and phone by one-time password, confirm the legal name and address, and complete the payments profile. Personal accounts also verify access to an Android device through the Play Console mobile app. Do this before the app is ready; it unblocks everything else.
Invite your team with limited permissions
Add developers, QA and your agency as users with permissions limited to the apps they work on. The account owner stays with the business, which keeps control of the app if a vendor relationship ends.
Create the app and set up signing
Create the app in Play Console, pick the default language, and enrol in Play App Signing so Google holds the app signing key while your team keeps an upload key. Store the upload key and its passwords in your own password manager, not on one developer’s laptop.
Complete App content declarations
Fill in the privacy policy URL, ads declaration, content rating questionnaire, target audience, Data safety form and any app access instructions reviewers need to log in. The Data safety form is required on every track except internal testing.
Build the store listing
App title up to 30 characters, short description up to 80 and full description up to 4,000. Add the icon, feature graphic and phone screenshots from the current build, plus tablet screenshots if you support tablets.
Run internal and closed testing
Upload an Android App Bundle to internal testing first (up to 100 testers) for a fast sanity check, then promote to closed testing. On a new personal account, this is where the 12-tester, 14-day clock runs.
Apply for production (if required) and release
Personal accounts apply for production access once the closed test is complete. Then create a production release, choose countries, add release notes and send it for review. The first release goes to everyone in the selected countries once approved.
Passing the 12-tester, 14-day closed test
For personal accounts created after 13 November 2023, Google requires a closed test with at least 12 testers who have opted in, running for 14 consecutive days, before you can apply for production. If a tester opts out and back in, their count restarts. Teams that recruit exactly 12 people and lose one in week two start again.
How we run it when a client is on a personal account:
- Recruit around 20 testers, not 12, from your target users rather than colleagues who will install once and forget.
- Use a Google Group or an email list as the tester list, so adding people doesn’t need a new release.
- Ship at least one update during the 14 days and ask testers to use the new build, so the test reflects normal use.
- Keep a short log of issues found and fixed, so the production access application can describe what was tested.
Closed testing lists can hold up to 2,000 users each, so there is no capacity problem. The constraint is engagement. If the business has a registered company, setting up an organisation account removes this step.
Register the Play account as an organisation from day one, start the D-U-N-S application immediately, and keep the account owned by the business. That one decision removes the closed-test requirement, the biggest delay on personal accounts, and keeps the app in your control.
The Data safety form: where declarations go wrong
Google’s Data safety help page is blunt: all developers with an app published on Google Play must complete the form, on closed, open and production tracks. That includes apps that collect no data, and a privacy policy is required either way. Only apps that live solely on internal testing are exempt.
The form covers data your SDKs collect, not just your own code, and Google says you alone are responsible for complete and accurate declarations. Inaccurate forms can lead to enforcement up to blocked updates or removal. The common mistakes we fix:
- Declaring “no data collected” while Crashlytics, Firebase Analytics or an ads SDK sends device and usage data.
- Forgetting that a login with email, or a support chat widget, collects personal information.
- Answering “data can be deleted” when there is no deletion flow on the backend.
- Updating an SDK that starts collecting a new data type, without updating the form.
For EU and UK users, the form is a store disclosure, not a legal basis for processing. Our guide to GDPR compliance for mobile apps covers consent and the rest of that work.
Want Play Console set up properly the first time?
We set up accounts, signing, listings, declarations and testing tracks inside your own Play Console. Send us your build status and target date; we reply within one business day.
Technical gates: target API and billing
From 31 August 2026, new apps and app updates must target Android 16 (API level 36) or higher, and the extension Google offered for apps that requested it lasts until 1 November 2026 at the latest. Wear OS and Automotive apps need API 35, and TV and XR apps API 34. Play Console won’t let you publish a new app or update below the requirement, so check targetSdkVersion before the release candidate, not after.
Targeting API 36 changes behaviour, notably on tablets and foldables, where Android 16 ignores orientation and resizability restrictions for most apps. That is testing work, not a one-line change. Apps that sell digital goods also need Play Billing Library v8 or later for new apps and updates from the same date.
Our guide to Google Play target API level requirements covers deadlines, the extension form and an upgrade plan.
Staged rollouts: why your first release can’t use one
According to Google’s staged rollout documentation, you choose a percentage of users, picked at random, and raise it manually. Staged rollouts work on production, open and closed tracks, but only for updates, not a first-time publish. This is the schedule we use for updates; the percentages are our practice, not Google’s.
| Stage | Rollout | Move on when |
|---|---|---|
| 1 | 5% for 1–2 days | No new crash cluster in Crashlytics or Android vitals, backend errors flat |
| 2 | 20% for 1–2 days | Crash and ANR rates in line with the previous version |
| 3 | 50% for a day | Reviews and support tickets show no pattern |
| 4 | 100% | Release complete; hotfix branch merged back |
Halting a rollout stops new users getting the version; users who already have it stay on it, so a halt must be followed by a fixed build. Once a rollout starts you can’t remove countries. Android vitals bad-behaviour thresholds are a 1.09% user-perceived crash rate and 0.47% ANR rate overall.
Protecting the first release instead
Since version 1.0 goes out to all selected countries at once, the protection has to come earlier. We use three levers. First, a longer closed or open test with real users, so the release build has run on a spread of devices before anyone can find it in search. Second, a narrower country list for the first release where marketing allows it, with more markets added in the next update. Third, server-side feature flags, so a risky feature can be switched off without waiting for review.
Play’s own tooling helps after launch. Android vitals uses a 28-day average, and going over the thresholds can reduce visibility and add a warning on your listing, so the first month’s stability matters for growth as well as reviews. The app launch checklist has the monitoring plan for the first 30 days.
Distributing outside Google Play: developer verification
If your app also ships as a side-loaded APK, through another store or as an internal enterprise build, there is a new step. Android now requires apps on certified devices to be registered by verified developers, whatever the download source. Verification means identity checks (organisations also verify their website through Google Search Console) and package name registration, proving ownership with an APK signed by your private key.
For apps on Play, Google says more than 99% were registered automatically, and the rest had to be registered by 30 September 2026. Installs from participating stores in Brazil, Indonesia, Singapore and Thailand on Android 7 and later are covered from that date, and Google has said it plans to expand globally in 2027, with no date given as of October 2026. Developers who distribute only outside Play use the new Android Developer Console. For enterprise and side-loaded client apps, registration is now on our release checklist.
Google Play publishing FAQs
How much does it cost to publish an app on Google Play?
Google charges a one-time US$25 registration fee, paid by credit card in the account holder’s legal name; prepaid cards are not accepted and the fee is not refunded if verification fails. There is no annual renewal, unlike Apple. Fees on digital sales depend on market, earnings tier, subscription vs one-off and whether you use Google Play Billing; for most small developers in the US, UK and EU they are now lower than the old 15–30%.
How long does Google Play review take?
Google does not publish a standard review time for production releases that we can quote. Our planning assumption is several days for a first release, so submit well before your launch date. The bigger delays are usually before review: D-U-N-S applications can take up to 30 days, and new personal accounts need a 14-day closed test.
Do I need 12 testers to publish on Google Play?
Only on a personal developer account created after 13 November 2023. Those accounts must run a closed test with at least 12 opted-in testers for 14 consecutive days before applying for production access. Organisation accounts are not subject to this rule, although we still recommend closed testing before any first release.
Do I have to fill in the Data safety form if my app collects no data?
Yes. Google requires every app published on closed, open or production tracks to complete the Data safety form, including apps that collect no data, and a privacy policy is required too. Only apps that sit solely on internal testing are exempt. Remember that SDKs count: crash reporting and analytics usually collect data.
Can I publish my app on Google Play to a few countries first?
Yes. You choose countries for each release, so a first release can go to a smaller list and later updates can add more markets. Note that once a staged rollout of an update has started, you can’t remove countries from it. Staged rollouts themselves are only available for updates, not the first publish.
Get your Android app live on schedule
Tell us your account type, build status and launch date. We reply within one business day with a Play Console plan and the dates that matter. Our app store submission services cover both stores.