I have three Android apps on Google Play: Finite, Pickly and QR & Barcode Scanner. All three are built with Flutter, and I published each of them alone.
Building the apps was the predictable part. Publishing an Android app on Google Play was where I lost the most time, mostly to things nobody mentions in tutorials. This post walks through the whole process and the mistakes I made, so you can skip them.
The short version
Publishing an app on Google Play comes down to seven steps:
- Create a developer account.
- Build a signed release version of the app.
- Write the store listing: name, descriptions, icon, screenshots.
- Fill in the policy forms: privacy policy, data safety, ads, content rating.
- Upload the build and send it for review.
- Fix whatever the review rejects, and resubmit.
- Release, then keep updating.
Steps three, four and six take longer than most people expect.
The developer account: personal or organization
A Google Play developer account costs a one-time fee of 25 US dollars. The more important choice is the account type.
Personal accounts created in the last few years have an extra requirement: before an app can go to production, it must pass a closed test with at least 12 testers for 14 days. For a solo developer without an audience, finding 12 people who keep a test app installed for two weeks is real work.
Organization accounts are exempt from that test. They need a registered business and a D-U-N-S number, which takes some paperwork to get.
My account is an organization account. If you plan to publish more than one app and you have a registered business, the paperwork is worth it. You do it once and every later app skips the testing period.
Building with Flutter
All three of my apps are written in Flutter. For a solo developer it has two clear advantages:
- One codebase and one language for the whole app, including the interface.
- Full control over the design. The app looks exactly as designed on every device, because Flutter draws its own interface.
I build for Android only. Publishing on iOS needs a Mac, and I do not ship iOS apps.
One habit saves a lot of trouble: test the release build on a real phone before every upload. A debug build can hide problems, such as missing permissions or code removed during optimization, that only appear in the version reviewers actually open.
App signing: the file you cannot afford to lose
Every Android app is signed with a key. With Play App Signing, Google keeps the final signing key, and you sign each upload with your own upload key.
That upload key lives in a keystore file on your computer. Lose the file or its password, and you cannot publish an update.
I know because I had to request an upload key reset for Pickly. Google can replace the key, so it is fixable, but releases are blocked until the request is processed.
Since then I keep the keystore and its passwords in two separate places, and I check the backup when I set up a new project.
The store listing: where I got rejected
The listing looks like marketing work. In practice it is also where policy problems hide.
Keyword stuffing in the description
My QR & Barcode Scanner listing was flagged for a metadata policy violation. The cause was keyword stuffing: I had repeated search terms in the listing to rank better.
Google's rule is simple once you have broken it. The title and descriptions must describe the app for a person, not list phrases for a search engine. I rewrote the description as normal sentences and the listing was accepted.
Icon mismatch
The same app was also flagged because the icon in the store listing did not match the icon the app shows on the phone. They have to be the same design. It sounds obvious, but when you redesign an icon late, it is easy to update one and forget the other.
Broken functionality
Pickly was rejected twice before it went live: once for broken functionality and once for a launcher icon problem.
The functionality rejection taught me the most. A reviewer opens the app cold, on their own device, and taps what they see. Anything that does nothing, crashes, or leads to an empty screen counts as broken, even if it works on your phone.
Before every submission I now go through the app as a stranger would: fresh install, no saved data, every button on every screen.
Policy forms: privacy, data safety and ads
These forms are not hard, but each one can block a release.
- Privacy policy. Every app needs a public URL with its privacy policy. Mine live on this site, one page per app.
- Data safety. You declare what data the app collects and why. It must match what the app and its libraries actually do.
- Ads. If the app shows ads, you say so. Pickly uses AdMob banner and interstitial ads, which also means declaring the advertising ID.
- app-ads.txt. Ad networks expect this small file on your developer website. It tells them who is allowed to sell ads in your app.
- Content rating. A short questionnaire that produces the age rating.
Fill these in honestly and early. Changing them after a rejection restarts the review.
Review times and what to expect
A review can take anything from a few hours to several days, and a new app from a new account usually waits longer than an update to an existing one.
Plan for at least one rejection on your first app. It is normal, and the rejection email usually names the policy. Fix exactly what it names, write a short note explaining the fix, and resubmit.
After launch
Publishing is the start of the work.
- Updates. Each update goes through review again, usually faster. The next version of Pickly adds notifications and an in-app review prompt.
- Screenshots and listing. Good screenshots change how many visitors install the app. I ended up building a small tool for myself to compose Play Store screenshots, because I was making them so often.
- Search visibility. App store optimization matters, but through relevance: a clear title, an honest description and the right category.
- Revenue. An honest note: an app supported by ads needs thousands of active users before the income means anything. Decide how the app will earn before you build it.
Checklist before you submit
- Release build tested on a real device, from a fresh install
- Every button and screen does something
- Store icon and launcher icon are the same design
- Description written as sentences, with no repeated keywords
- Privacy policy URL is live and reachable
- Data safety form matches what the app collects
- Ads declared, and app-ads.txt published if you use an ad network
- Keystore and passwords backed up in two places
- Screenshots show the real app, in the right sizes
Frequently asked questions
How long does it take to publish an app on Google Play?
The upload takes minutes. The review takes from a few hours to several days. For a new personal account, add the 14-day closed test before production. Preparing the listing and policy forms properly takes a day or two the first time.
Do I need 12 testers to publish an Android app?
Only with a personal developer account, where a closed test with at least 12 testers for 14 days is required before production access. Organization accounts do not have this requirement.
How much does it cost to publish on Google Play?
The developer account is a one-time fee of 25 US dollars. There is no fee per app. Google takes a share of in-app purchases and subscriptions, but not of ad revenue.
Why was my app rejected by Google Play?
The most common reasons are broken functionality, misleading or keyword-stuffed listings, icon or screenshot mismatches, and data safety forms that do not match the app. The rejection email names the policy, so start there.
Is Flutter good for Android apps?
Yes. Flutter produces fast Android apps from one codebase and gives full control over the design. All three of my published apps are built with it.
Need an Android app built and published?
I build Android apps with Flutter and take them all the way to a live Google Play listing. You can see mine on the apps page. If you have an app in mind, write to collab@vhirty.com.
