App Store + Play Store Release Checklist for Flutter Apps (2026)

You built the app. Tests pass. Firebase is configured.
Then App Store review rejects you for a missing privacy declaration, and Google Play flags your data safety section.

Store release is a separate skill from Flutter development — and it catches teams off guard every time. This checklist covers both Apple and Google requirements for Flutter apps in 2026, based on shipping production apps across logistics, wellness, mental health, and eCommerce — including apps that reached 1M+ users on the store.

Pre-Release: Project Setup

Flutter build configuration

• App version and build number set correctly in pubspec.yaml (version: 1.0.0+1)
• App name, bundle ID / application ID finalized — changing later is painful
• App icons generated for all required sizes (iOS and Android)
• Splash screen configured for both platforms
• Release build tested — not just debug (flutter build apk --release, flutter build ios --release)
• ProGuard / R8 rules configured for Android if using plugins that require keep rules
• iOS deployment target set to a supported minimum (check plugin requirements)

Signing and certificates

iOS:

• Apple Developer account active ($99/year)
• Distribution certificate and provisioning profile created
• App ID registered with required capabilities (Push, Sign in with Apple, etc.)
• Xcode archive builds successfully
• TestFlight internal testing completed on real devices

Android:

• Play Console developer account active ($25 one-time)
• Upload keystore created and backed up securely — losing it means you cannot update the app
• key.properties configured, not committed to git
• App bundle built (flutter build appbundle) — Google requires AAB, not APK, for new apps
• Internal testing track used before production rollout

Privacy and Compliance

Both stores now scrutinize data collection heavily. This is the most common rejection reason in 2026.

Apple App Store

• Privacy Nutrition Labels completed in App Store Connect — every data type collected declared accurately
• App Tracking Transparency (ATT) prompt implemented if using tracking frameworks
• Sign in with Apple offered if you provide Google/Facebook login (Apple requirement)
• Account deletion available in-app if account creation exists (Apple requirement since 2022)
• Privacy policy URL live and linked in App Store Connect
• Permission usage descriptions in Info.plist — camera, location, photos, microphone, notifications (clear, user-facing copy — not "we need camera access")

Google Play Store

• Data safety section completed in Play Console — matches actual SDK and Firebase data collection
• Permissions declared match manifest — remove unused permissions
• Privacy policy URL linked
• Target API level meets Google's current requirement (check latest Play policy — typically current or previous Android API)
• Families policy compliance if app targets children

Firebase-specific disclosures

If you use Firebase, declare accurately:

• Analytics (usage data)
• Crashlytics (diagnostics)
• Auth (email, identifiers)
• Firestore / Realtime Database (user content, if applicable)
• Cloud Messaging (device identifiers)

See Flutter + Firebase Production Checklist for the full Firebase production gate.

Store Listing Assets

Required for both stores

• App name (30 chars iOS, 50 chars Google — check current limits)
• Short description / subtitle
• Full description — clear value proposition, not keyword stuffing
• Screenshots for required device sizes (iPhone 6.7", 6.5", iPad if supported; Android phone and optionally tablet)
• Feature graphic (Google Play — 1024 x 500)
• App category selected correctly
• Content rating questionnaire completed (IARC for Google, age rating for Apple)
• Support URL and contact email

Quality tips

• Screenshots showing real app UI, not marketing mockups alone
• First screenshot communicates core value in 3 seconds
• Localized listings if targeting non-English markets

Functional Pre-Launch Testing

• Full user flow tested on physical iOS and Android devices
• Push notifications work on release builds (not just debug)
• Deep links and universal links tested
• In-app purchases tested in sandbox (Apple) and test track (Google)
• Login flows including Apple Sign-In and Google Sign-In on release builds
• Offline behavior tested — see Building Offline-First Flutter Apps
• No debug logging, test API keys, or staging URLs in release build
• Crashlytics receiving crashes from beta builds

App Review Preparation

Apple-specific

• Demo account credentials provided in App Review Information if login required
• Review notes explain non-obvious features or hardware requirements
• Export compliance answered (most apps using standard encryption select "No" for proprietary encryption)
• App does not reference Android or other platforms in UI or metadata
• In-app purchase products approved in App Store Connect before submission

Google-specific

• Closed or open testing track used before production (recommended minimum 14 days for new developer accounts under updated policy)
• Pre-launch report reviewed in Play Console — fix critical issues flagged
• App content declarations complete (ads, news, COVID, etc. — as applicable)

Release Strategy

Do not ship 100% on day one unless you have strong confidence and monitoring in place.

Recommended rollout

1. Internal testing — team and stakeholders (1–3 days)
2. Closed beta / TestFlight external — trusted users (1–2 weeks)
3. Staged rollout — Google Play percentage rollout (10% → 50% → 100%)
4. Phased release — Apple phased release over 7 days (optional)

Rollback plan

• Previous build version archived and ready to republish if needed
• Remote Config kill switches for risky features
• On-call or monitoring alert for crash rate spikes post-release
• Known issue communication plan for support channels

Post-Launch Monitoring (First 72 Hours)

• Crashlytics crash-free rate above your threshold (aim for 99%+)
• Analytics funnel for signup / core action — compare to beta
• Store reviews monitored and responded to
• ANR rate on Android within Play Console thresholds
• Server / Firebase costs monitored for unexpected spikes

Common Rejection Reasons (Flutter Apps)

Version Updates After Launch

Every subsequent release should include:

• Incremented build number (required every submission)
• Changelog / release notes for users
• Regression test on critical paths
• Updated privacy declarations if new data collection added
• Staged rollout for non-trivial changes

How This Connects to Your Broader Stack

Store release is the last gate — not the first. If auth, offline behavior, or Firebase rules are not production-ready, store approval just means more users hit the bugs faster.

Recommended reading before your first submission:

• Flutter + Firebase Production Checklist
• Best Architecture for Scalable Flutter Apps
• How Much Does It Cost to Build a Flutter App in 2026

If you are hiring help for launch, How to Hire a Flutter Developer in 2026 includes store release experience as a key evaluation criterion.

Need Help Getting Across the Line?

Store rejections are expensive when you are racing to launch. I help startups ship Flutter apps to both stores with the signing, privacy, and review prep handled as part of the delivery — not as a surprise at the end.

See case studies for apps shipped to production, or Flutter app development services to discuss your release timeline.