QA passed. Marketing scheduled the announcement. Then App Store Connect rejected the build for a missing privacy manifest. Play Console flagged the data safety form. TestFlight testers saw a white screen on first open because production API keys were not set.
Store submission is a gate separate from "feature complete." Flutter compiles to both stores, but Apple and Google review different artifacts, policies, and metadata. This checklist is what we run before calling a Flutter release done, distinct from deep links or state management work covered in other posts.
We ship cross-platform mobile delivery with teams who need predictable store releases, not Friday-night fire drills.
Mental model: three layers
- Flutter build (release mode, correct flavor, env config)
- Store accounts (Apple Developer, Google Play Console, signing assets)
- Policy surfaces (privacy, permissions, content rating, screenshots)
Fail any layer and the binary never reaches users.
Pre-build: environments and secrets
- [ ] Production API base URL in release flavor (not staging)
- [ ] Secrets not committed; CI injects keys for release builds
- [ ] Version
pubspec.yamlbump matches store intent (version: 1.2.0+42) - [ ] Obfuscation / ProGuard rules tested if enabled (crash on launch = common miss)
- [ ] Feature flags default safely for public release
Run flutter build apk --release and flutter build ipa (or CI equivalents) from clean checkout.
iOS: App Store Connect and TestFlight
Signing and bundle
- [ ] Bundle ID matches App Store record
- [ ] Distribution certificate and provisioning profile valid
- [ ] Icons all required sizes; no alpha channel on App Store icon
- [ ] Launch screen configured (not blank flash)
TestFlight
- [ ] Internal testers receive build
- [ ] Cold start on physical device (not only simulator)
- [ ] Push notifications if used: production APNs entitlement
- [ ] In-app purchases sandbox-tested if applicable
App Store review prep
- [ ] Privacy Nutrition Labels / privacy manifest accurate for SDKs used
- [ ] App Privacy Policy URL live
- [ ] Export compliance questions answered
- [ ] Review notes with test account credentials if login required
- [ ] Guideline 4.2 risk: minimum functionality if app is thin wrapper
Common rejection: missing purpose strings in Info.plist for camera, photos, location, tracking.
Android: Play Console
Signing and bundle
- [ ] Play App Signing enabled; upload key secure
- [ ] AAB uploaded (not legacy APK unless required)
- [ ]
applicationIdmatches Play listing - [ ] Target SDK meets current Play requirements
Store listing
- [ ] Data safety form matches app behavior (SDKs, collection, sharing)
- [ ] Content rating questionnaire complete
- [ ] Screenshots and feature graphic for required form factors
- [ ] Privacy policy URL
Pre-launch report
- [ ] Run internal testing track first
- [ ] Review pre-launch crash report
- [ ] Test back button, permissions flows, offline behavior
Common rejection: data safety mismatch with actual analytics or login SDK behavior.
Flutter-specific gotchas
| Issue | Check |
|---|---|
| White screen on release |
--dart-define missing in CI release job |
| Plugin crash only in release | ProGuard keep rules for plugin |
| Wrong app name on home screen |
AndroidManifest label / iOS CFBundleDisplayName
|
| Deep links broken in store build | Associated domains and intent filters in release manifest |
| Huge binary size | Split per ABI; strip debug symbols appropriately |
Test release builds. Debug mode hides many integration failures.
Backend and API readiness
Store review may hit live APIs:
- [ ] Production backend scaled for review period traffic
- [ ] Account creation flows work without manual approval
- [ ] Rate limits will not block Apple/Google reviewer IPs
- [ ] Terms and support email reachable
Coordinate with backend owners the same week as store submission.
Metadata and marketing alignment
- [ ] Store description matches actual v1 features (no aspirational bullets)
- [ ] Screenshots from current UI build
- [ ] Version release notes written for users, not commit log
- [ ] Marketing site and store links consistent
Launch day runbook
- Promote build from internal to production track
- Monitor crash-free sessions (Firebase Crashlytics, Sentry)
- Watch reviews first 48 hours
- Keep hotfix branch ready for copy or config-only resubmission
Apple review times vary; plan announcement with buffer, not same-hour dependency.
After first release: cadence
- Track SDK updates that trigger new privacy questions
- Renew Apple agreements and certificates before expiry
- Play target SDK deadlines on calendar
- Align Flutter stable channel upgrades with store regression pass
Practical takeaway
Treat App Store and Play Console as part of definition of done. Release builds, policy forms, and production backends get the same checklist discipline as widget tests.
If you are planning a first Flutter store release and want a scoped launch review, scoping a mobile product launch with a team that ships both stores is a reasonable next step.
What rejected your last build: privacy labels, data safety, or a release-config white screen?













