Flutter Play Store Launch Checklist: Avoid Rejection in 2026
Google Play's review process differs from Apple's in ways that trip up Flutter developers. Where Apple leans on human review, Google leans on automated policy scanning — which means a rejection often arrives fast, and the reason is usually a mismatch between what your app declares and what it actually does.
This is a Flutter-specific Play Store launch checklist. You can run through it manually, or run an automated Launch Score scan that checks the mechanical items in a few minutes by uploading your project zip.
How Play Store review differs from App Store review
Play Store review is heavily automated. Policy scanners inspect your app's manifest, declared permissions, SDK behavior, and data practices before a human ever looks at it. That has two consequences for Flutter developers: rejections come quickly (often within hours), and the rejection cause is usually a declared-vs-actual mismatch rather than a subjective judgment about your app's value.
Flutter adds a wrinkle: your Dart code is shared, but your Android configuration is still built separately. A `release` build can behave differently from a `debug` build in ways that only surface at submission — `debuggable` flags, permission declarations, and network security config all differ between build variants.
The checklist
1. android:debuggable not enabled in release
This is the most common Play Store issue for Flutter apps. android:debuggable="true" ships debug hooks into your production APK. It gets in by accident — a copied manifest entry, a build variant misconfiguration, or a debug flag that was never scoped to the debug build type. Play Store does not always catch it, and relying on that is not safe. Confirm your release build variant sets it to false.
2. Declared permissions match actual usage
If your app makes network calls, the INTERNET permission must be declared — without it, calls fail silently in release. The inverse is also a problem: declaring permissions you don't use (camera, location, contacts) invites review questions and can trigger a data-safety form mismatch. Audit your manifest against what your app actually does.
3. Data Safety form matches actual SDK behavior
The Play Console Data Safety form asks what your app collects and shares. The common rejection: the form says your app collects nothing, but a third-party SDK (analytics, crash reporting, ads) collects more than you declared. The scanner compares declared behavior against actual SDK behavior. Audit every SDK in your pubspec.yaml for what it collects, and make the form match.
4. No unpinned git dependencies
A git dependency pointed at a branch ref (not a tag or commit) can change your build without warning. A maintainer pushes to main and your next clean build behaves differently — sometimes in a way that breaks a Play Store policy. Pin git dependencies to a tagged version or a specific commit before submission, when you want reproducibility.
5. usesCleartextTraffic not blanket-enabled
Android's Network Security Config is the equivalent of iOS App Transport Security. android:usesCleartextTraffic="true" allows cleartext (HTTP) traffic app-wide. If your app only talks to HTTPS endpoints, you should not need this. If you have a specific legacy domain that requires HTTP, scope the exception to that domain rather than enabling it globally — a blanket bypass invites review questions.
6. Signing config is correct for release
A release build needs a valid signing config (keystore). A common failure: the app builds in debug with an auto-generated debug keystore, but the release build fails or is unsigned because the production signing config was never wired into build.gradle. Verify the release variant produces a signed APK or AAB before you start the upload.
7. Target SDK and min SDK meet current Play requirements
Google raises the required target API level annually. Submitting an app targeting an API level below the current Play Store requirement gets rejected before review. Confirm your compileSdkVersion and targetSdkVersion meet the current Play Console target API requirement for new apps.
8. Crash reporting initialized before runApp
Crash reporting (Sentry or Firebase Crashlytics) must be initialized before runApp() — not just installed in pubspec.yaml. The most common "looks done, isn't" finding: the SDK is present but runApp() was never wrapped in the init call, so it captures nothing. Play Store doesn't reject you for this, but you find out only when a real crash goes unreported in production.
Release-mode smoke test
Before you submit, build a real release APK and run it on a device or emulator — not a debug build. Many of the items above (debuggable flag, cleartext traffic, permission behavior) only manifest in release mode. A release-mode smoke test catches what debug mode hides.
The checklist above catches the mechanical, pattern-matchable issues. What it doesn't replace is judgment about Play policy edge cases specific to your app's category. Run the scan to clear the mechanical rejections, then review the policy edge cases yourself.
Run your scan
If you're about to submit a Flutter app to Google Play, run a free Launch Score scan first — it checks the Android-specific items above in a few minutes, before a scanner does.
Frequently asked questions
What do I need to publish a Flutter app on Google Play?
To publish on Google Play: create a Google Play Console account ($25 one-time fee), generate a signed Android App Bundle (.aab), create a store listing with screenshots and description, set up content rating, configure data safety form, and complete the 14-day closed testing requirement if you have a new personal account.
Should I upload an APK or AAB to Google Play?
Upload an Android App Bundle (.aab), not an APK. Google Play uses App Bundles to generate optimized APKs for each device configuration, reducing app size. APKs are only accepted for internal testing tracks.
How do I sign my Flutter app for Google Play?
Generate a keystore file with keytool, configure it in android/key.properties, update android/app/build.gradle to use the signing config, then build with flutter build appbundle. This produces a signed .aab ready for upload to Google Play.