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

1. Flutter build (release mode, correct flavor, env config)
2. Store accounts (Apple Developer, Google Play Console, signing assets)
3. 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.yaml bump 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)
• [ ] applicationId matches 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

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

1. Promote build from internal to production track
2. Monitor crash-free sessions (Firebase Crashlytics, Sentry)
3. Watch reviews first 48 hours
4. 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?