How to publish an app on Google Play in 2026
The process changed, and most of the tutorials that come up in search predate the change. The difference is not cosmetic: there is now a testing requirement that holds a new app for at least two weeks, and people who do not know about it find out on the day they meant to launch.
This guide is about Google's process, from zero to the app being available.
Four things before you start
- A developer account, which costs US$ 25 once. Not per app, not per year;
- Identity verification. Google checks who you are against a document, and it takes a few days. Start here, because it is the step that waits on somebody else;
- The app file, as an Android App Bundle (
.aab). The.apkyou install on your own phone to test is not what you publish; - A privacy policy at a public address. It is mandatory, including for an app that collects nothing.
The decision that changes everything: personal or organisation account
This is the first choice in the process and the one that sets how long you will take. It almost never appears at the top of a tutorial, and it should.
| Personal | Organisation | |
|---|---|---|
| What it needs | an identity document | the company's D-U-N-S number |
| Mandatory closed test | yes, if the account was created after 13/11/2023 | no |
| Who appears on the store | you | the company |
| Time until you can publish | two weeks minimum, because of the test | however long review takes |
If you have a registered company and intend to keep the app for years, the organisation account skips the slowest part of the process. A D-U-N-S number is free and takes a few days to issue.
If you are publishing as an individual, the next section is your critical path.
The closed test: 12 people for 14 days
Personal accounts created after 13 November 2023 have to test the app before it is eligible for distribution. The rule, from Google's own page:
- 12 testers in the closed test;
- for 14 continuous days;
- and the part that catches nearly everyone: someone who opts in, tests for fewer than 14 days and opts out does not count. Testers have to stay opted in, continuously, for the whole period.
Once the requirement is met, you apply for production access on the dashboard in Play Console. When it is approved, the production track and open testing become available.
What that means in practice. The calendar does not start when the app is ready, it starts when the twelfth tester accepts the invitation. Three pieces of advice that save weeks:
Invite more than twelve. Somebody will change phones, somebody will uninstall without saying so. Inviting twenty to secure twelve is normal, not excessive.
Explain that installing is not the whole job. People have to stay opted in for the 14 days. A clear message at invitation time is what stops you discovering on day thirteen that the count never closed.
Start the test before the app is perfect. The clock runs in parallel with your polishing. Holding the test back for a final version throws two weeks away.
The steps
- Create the account in Play Console, choose personal or organisation, pay the US$ 25 and complete identity verification;
- Create the app in the console: name, default language, app or game, free or paid. The free-or-paid choice cannot be undone once it has been published as free;
- Fill in the store listing: title, short description, full description, icon, feature graphic and screenshots. Screenshots are what decides installs more than anything else, and they are the part most people treat as paperwork;
- Answer the content rating questionnaire. It is a form, and answering it optimistically is grounds for removal later;
- Fill in the data safety form, declaring what the app collects and shares. It has to match what the app really does;
- Upload the
.aabto a testing track; - Run the closed test, if your account needs one;
- Apply for production access and submit for review.
The most common rejections
Almost all of them are paperwork, not code:
Data safety that does not add up. You declared that nothing is collected and the app has sign-in, or uses an analytics tool. Anything that identifies a person counts.
A privacy policy that does not open. A broken link, a page behind a login, an address that only works on your own machine.
An optimistic rating. User-generated content without declaring that user-generated content exists is the classic case.
An outdated target API level. Google requires new apps to target a recent Android version, and the bar rises every year.
A permission with no justification. Asking for location, camera or contacts without the use being clear in the listing invites a request for explanation.
And if you do not have the app yet
Everything above is Google's process, and it holds however the app was built. The earlier part, having a packaged and signed Android app at all, is where most people stall, because it historically required a development environment set up on a machine.
That is what changed. You can now describe the app, publish it as a site and have it packaged as a native app, with no environment to set up. On Fabapp the app is submitted under your own developer account, not ours: the store listing is yours, and the relationship with Google is yours. That difference matters on the day you want to leave.
What the platform does not do for you, and could not: create the account, pass identity verification, and complete the 12-tester test. That is between you and Google. Everything the platform does is on features.
If you are already a customer and want the exact screen where this happens, the walkthrough inside the product is in the guide Publishing your app to the stores. This page is about Google's process; that one is about where to click.
The summary, in three lines
The money is small, US$ 25 once. Time is the real cost, and it is dominated by the 12 people for 14 continuous days when the account is personal. And rejections are almost never technical: they are forms filled in a hurry.
On Fabapp the Free plan does not ask for a card, so you can have the app standing before spending the US$ 25 with Google.