Getting a Flutter app past App Review or Google Play’s automated checks feels straightforward until your submission bounces back over a missing purpose string or a mismatched bundle ID. Most rejections come down to a handful of predictable oversights — the kind that are easy to miss when you’ve been heads-down in Dart for months.
Table of Contents
This checklist covers the eight things most likely to trip you up before you hit submit, for both the iOS App Store and Google Play. Work through each item once and you’ll avoid the days of back-and-forth that first-time submitters often run into.
Quick Answer
Before submitting a Flutter app, verify your pubspec.yaml version numbers, code signing setup, build format (AAB for Android, IPA for iOS), target SDK levels, permissions, privacy policy URL, store assets, and that you’ve tested a release build on a real device — not just in debug mode.
The 8-Item Flutter Submission Checklist
1. Version numbers in pubspec.yaml. Your version follows the format version: 1.0.0+1, where the number before the plus sign is the user-visible version name and the integer after it is the build number. Both stores require the build number to increment with every upload — submitting the same build number twice will cause an immediate rejection. Start new projects at 1.0.0+1 and never reuse a build number.
2. Code signing is configured correctly. On iOS, you need a valid Distribution Certificate and an App Store Provisioning Profile generated in Apple’s Certificates, Identifiers & Profiles portal. After April 28, 2026, Apple requires all submissions to be built with Xcode 26 or later. Open ios/Runner.xcworkspace, set the build target to Any iOS Device (not a simulator), and confirm signing under Product > Archive before running flutter build ipa –release. On Android, generate your upload keystore with keytool -genkey -v -keystore ~/upload-keystore.jks -keyalg RSA -keysize 2048 -validity 10000 -alias upload, reference it in key.properties, and keep both files out of version control. Because new apps must enroll in Play App Signing, Google holds the actual app signing key — if you ever lose your upload keystore, you can request an upload key reset through the Play Console (Setup > App integrity) and continue publishing without losing your app listing.
3. You’re building in the right format. Android requires an Android App Bundle (.aab), not a fat APK. Run flutter build appbundle –release to produce the correct artifact. Adding –obfuscate –split-debug-info=build/app/outputs/symbols obfuscates your Dart code and keeps debug symbols out of the bundle. For iOS, flutter build ipa –release produces the signed archive ready for upload via Xcode Organizer or the Transporter app.
4. SDK targets meet store requirements. For Android, your build.gradle must set both compileSdk = 35 and targetSdk = 35 — Google Play requires apps to target Android 15 (API level 35) for new submissions and updates. Setting minSdk = 24 covers the large majority of active Android devices. For iOS, your project must be built with Xcode 26 or later for submissions after April 28, 2026. Run flutter doctor -v to confirm your toolchain versions before building.
5. Permissions are trimmed and described. Open AndroidManifest.xml and audit every
6. A hosted privacy policy is in place. Both stores require a privacy policy URL that resolves to a live page — not a PDF, not a Google Docs link, not a staging URL. The policy must describe what data you collect and how it’s used. On iOS, you enter this URL in App Store Connect under App Information and must also complete the App Privacy labels (the ‘nutrition label’ for data collection). On Android, fill out the Data Safety section in Play Console accurately — mismatches between what you declare and what your app actually does can trigger removal after launch.
7. Store assets meet spec. On iOS, your app icon must be 1024×1024px with no transparency, and screenshots for the iPhone 6.9-inch display (1320 × 2868px) are mandatory as of 2026 — missing this size blocks submission. On Android, your store icon must be 512×512px PNG with alpha, and a 1024×500px feature graphic is required. Use flutter_launcher_icons to auto-generate the full set of mipmap directories from a single source image, and generate adaptive icons (transparent foreground layer, solid background) to avoid a plain-square fallback on Android 8+. Remove any debug overlays from screenshots — they cause rejection.
8. You’ve tested a release build on a real device. Running flutter run –release on a physical phone is not optional. Release builds disable debug tooling and apply ProGuard/R8 obfuscation, which can surface crashes and broken deep links that were invisible during development. On iOS, distribute to at least a few testers through TestFlight before submitting — Apple recommends validating on TestFlight as a final gate. On Android, use the Internal Testing track in Play Console (typically approved within 30 minutes) to catch any install or launch issues before pushing to production.
Platform-Specific Gotchas Worth Knowing
On iOS, bundle ID consistency is a frequent pain point. The bundle ID must match exactly across your Apple Developer account, App Store Connect record, Xcode’s Runner target, and any third-party services like Firebase. A single mismatch causes signing failures that are time-consuming to untangle. Also confirm that CocoaPods or Swift Package Manager resolves cleanly on your build machine by running pod install from the ios/ directory before archiving.
On Android, bundle size can quietly creep past store limits if you’re not compressing assets. Convert images to WebP format, enable shrinkResources = true and minifyEnabled = true in your release build type, and verify the final AAB size in Play Console’s artifact explorer after upload. Also note that Play App Signing is now required for all new apps — Google securely holds the app signing key and you submit with a separate upload key, which means you can recover from a lost upload keystore by requesting a key reset through the Play Console without losing your app listing.
For apps with user accounts on either platform, both Apple and Google require you to provide a way for users to delete their account from within the app — not just a mailto link. If your app doesn’t have this and you request account-creation, expect rejection.
Common Mistakes That Cause Delays
Submitting without test credentials. If your app requires login and reviewers can’t access it, Apple will reject immediately. Provide demo credentials in the Notes field of App Store Connect’s App Review Information section. Google Play has the same requirement under the App Content section. Use a dedicated reviewer account so you’re not exposing real user data.
Skipping TestFlight or Internal Testing. Uploading straight to production review with an untested build risks catching a crash after the clock starts on review. Both platforms allow pre-release testing tracks that give you a chance to catch launch bugs. The time invested is almost always less than the time lost to a rejection and resubmission cycle.
Forgetting to increment the build number between submissions. If a build is rejected and you fix the issue, you must bump the build number — even if the version name stays the same — before re-uploading. Submitting the same build number after changes is a common source of ‘build already exists’ errors.
Leaving debug flags in. Double-check that dart:developer, debugPrint, and any logging packages are not writing sensitive data in release mode. Flutter automatically strips most debug assertions, but third-party logging libraries may need explicit configuration to stay quiet in production.
Explore more: App Development guides and tutorials.
Flutter App Store Submission FAQs
What’s the difference between flutter build appbundle and flutter build apk?
flutter build appbundle produces an Android App Bundle (.aab), which is required for Google Play submissions. The Play Store uses the AAB to generate optimized APKs for each device configuration, reducing download size. flutter build apk produces a single APK file, which works for direct distribution and testing but cannot be submitted to the Play Store for new apps or updates.
What happens if I lose my Android upload keystore?
If your app is enrolled in Google Play App Signing (required for all new apps), losing your upload keystore is not fatal. Google holds the actual app signing key, so you can request an upload key reset through the Play Console under Setup > App integrity. After submitting the request with a new certificate, Google typically processes it within a few business days and you can resume publishing updates without losing your app listing.
Do I need a separate Apple Developer account for each Flutter app I publish?
No. One Apple Developer Program membership ($99/year for individuals) lets you publish as many apps as you want under your account. You manage each app as a separate record in App Store Connect. The same applies to Google Play — the $25 one-time registration fee covers unlimited app publications under that developer account.
Build It With GTStudios
Need help shipping your app, game, or small-business tech? GTStudios builds web, apps, and games. See how GTStudios can help.
Photo by Fahim Muntashir on Unsplash.