Publishing Your Flutter App to the Play Store, the Easy Way

Building the app is the fun part. Getting it in front of real users through the Play Store feels like the boring part, right up until your first install count ticks up from zero. Here's the whole path, in order, with nothing skipped.

1. Get a Google Play Developer Account

Head to play.google.com/console, pay the one-time $25 registration fee, and complete identity verification. This can take anywhere from a few hours to a couple of days, so do it before you need it, not the night before a launch.

2. Prepare Your App for Release

Set your app identity

Set a permanent applicationId in android/app/build.gradle — once published, this can never change. Bump versionCode for every single upload (it must always increase) and versionName for the human-readable version users see.

Add icons and splash screens

Use the flutter_launcher_icons package to generate every required icon size from one source image instead of exporting a dozen PNGs by hand.

3. Sign Your App

The Play Store requires every release to be cryptographically signed. Generate an upload keystore once and reuse it for every future release.

keytool -genkey -v -keystore ~/upload-keystore.jks \
  -keyalg RSA -keysize 2048 -validity 10000 \
  -alias upload

# android/key.properties (never commit this file)
storePassword=<your-store-password>
keyPassword=<your-key-password>
keyAlias=upload
storeFile=/absolute/path/to/upload-keystore.jks

Reference key.properties from android/app/build.gradle's signingConfigs, and add key.properties and *.jks to .gitignore. Losing this keystore means you can never update your app under the same listing again, so back it up somewhere safe outside the repo.

4. Build the Release Bundle

flutter build appbundle --release

The Play Store requires an Android App Bundle (.aab), not an APK. Google uses it to generate optimized, device-specific downloads, which means smaller installs for your users and no extra work for you.

5. Set Up Your Store Listing

• Screenshots for phone (minimum 2) and, if relevant, tablet
• A 1024x500 feature graphic
• Short description (80 characters) and full description (up to 4000)
• A privacy policy URL — required even for the simplest app that touches the internet
• Completed content rating questionnaire
• Target audience and Data Safety form, listing exactly what data your app collects

6. Upload and Roll Out

Don't push straight to production. Upload the .aab to an Internal testing track first to sanity-check the build, then move to Closed or Open testing with a small group of real users. Only promote to Production once you're confident, and even then, consider a staged rollout (say, 20%) so a bad build only reaches a fraction of users before you catch it.

7. Review and Go Live

Review typically takes anywhere from a few hours to a few days. The most common rejection reasons are a missing or broken privacy policy link, permissions the app requests but doesn't justify, and a Data Safety form that doesn't match what the app actually collects. Get those right up front and most reviews sail through.

Quick Checklist Before You Hit Submit

• versionCode incremented from the last release
• Upload keystore backed up outside the repo
• Privacy policy URL live and correct
• Data Safety form matches actual data collection
• Tested the signed release build on a real device, not just debug mode
• Staged rollout percentage set for the first production release

None of this is hard, it's just sequential. Do it once, write down your keystore location and package name somewhere safe, and every release after the first takes minutes.