Flutter Deployment 2026: The Play Store and App Store Checklist

Shipping a Flutter app to the App Store and Google Play in 2026 is different from 2024 in ways that will get you rejected if you are working off older guides. Android targetSdk 35 is mandatory, 16KB memory pages are now enforced, Play Integrity replaced SafetyNet entirely, and on iOS the 26 SDK is the minimum submission SDK as of April 28, 2026. This is the deployment checklist I actually run through for every release.

Short version: bump compileSdkVersion and targetSdkVersion to 35, rebuild your native libs with 16KB page alignment, switch from SafetyNet to Play Integrity, update to Xcode 26 for iOS submissions, double-check your privacy manifest, and run through the dual-store checklist below. A 48-hour release runbook closes the post. Print it before your next launch day.

What changed for Flutter deployment in 2026

Four platform-level changes matter most. If any of them catch you off-guard at submission time, your release slips by days, not minutes.

If your Flutter app is on Flutter 3.32 or newer with a current toolchain, the Android changes are mostly configuration. The iOS change is operational (upgrade your local Xcode and the CI runner image).

Android checklist: targetSdk 35, AAB, 16KB, Play Integrity

Order matters here. Fix the build config first, then the submission assets, then the policy surface.

• compileSdkVersion 35 and targetSdkVersion 35. Both live in android/app/build.gradle. Google Play rejects uploads below target 35 for new apps and for updates of existing apps.
• Flutter version. Flutter 3.29 and newer compile against Android SDK 35 out of the box. Upgrade if you are still on 3.24 or older.
• NDK version. Your android/app/build.gradle should pin ndkVersion = "27.0.12077973" or newer. The older 25 series does not produce 16KB-aligned .so files for arm64 and x86_64 and Play will reject.
• Android App Bundle (AAB), not APK. AAB has been mandatory for new apps since 2021, but any sideloaded APK release should also be AAB. Build with flutter build appbundle --release.
• Play App Signing enabled. Upload your app-signing key to Google Play so Play handles per-device signing. This is enabled by default for new apps but double-check in the Play Console under Setup, App Integrity.
• Play Integrity API wired. If you do any server-side attestation (abuse prevention on Cloud Functions, paywall verification), you must use Play Integrity. SafetyNet attestations stopped being accepted in Q4 2024.
• Data Safety form complete. Every data type your app collects, every purpose, every optional or required disclosure. Mismatches between the form and actual behavior are a rejection cause Google enforces aggressively in 2026.
• Content rating submitted. IARC questionnaire, take it seriously. Wrong answers delay release.
• App category, tags, screenshots. 8 screenshots for phone and tablet, 1080 x 1920 or the safe universal 1080 x 2400. Add a 16:9 feature graphic.
• In-app purchase products configured. If you use RevenueCat, set products up there and in the Play Console. Test with license testers before internal testing release.

iOS checklist: iOS 26 SDK, signing, privacy, StoreKit

The iOS side is shorter but strict. Most indie Flutter devs already have these in order; the April 28, 2026 iOS 26 SDK mandate is the single new hard gate.

• Xcode 26. Install it locally and on CI. Flutter 3.32 supports Xcode 26 out of the box. You cannot submit to the App Store with older Xcode after April 28, 2026.
• iOS deployment target. Common indie choice in 2026 is iOS 16 minimum, which covers 97 percent of devices. Set it in ios/Podfile and in Xcode.
• Sign in with Apple. If you offer any other third-party login (Google, Facebook), Apple requires Sign in with Apple too. This is a hard rejection if you miss it.
• Privacy manifest current. PrivacyInfo.xcprivacy in the iOS runner and every SDK. The iOS-side guide is here. Even on a Flutter app, you add the manifest via the Xcode project, not Dart.
• Tracking transparency. If any bundled SDK collects IDFA, add anNSUserTrackingUsageDescription and trigger the ATT prompt.
• StoreKit testing. Use a StoreKit Configuration file in development, and sandbox buyers for UAT before release.
• TestFlight build. Ship at least one TestFlight build to external testers 24 hours before a production submission.
• App Review notes. Paste demo credentials, any external purchase link rationale, and a one-line explanation of each permission the app requests. Reviewers read them and reject noticeably less often on apps with clear notes.
• Screenshots. Six screenshots at 6.9 inch (iPhone 16 Pro Max) and 12.9 inch (iPad Pro) sizes as the minimum 2026 set.

Data Safety plus App Privacy parity

Both stores now cross-check your privacy declarations against your app's actual behavior. In 2026 I have seen rejections on both stores for drift between a Flutter app's analytics code and the declared data types.

Keep one source of truth. I recommend a markdown file at docs/privacy-inventory.md that lists every data type collected, why, whether it is linked to the user, whether it is used for tracking, and which SDK writes it. Before every release, diff the file against the Google Play Data Safety form and the App Store Connect App Privacy questionnaire.

The common miss is analytics SDKs. PostHog, Mixpanel, and Firebase Analytics all collect stable identifiers that count as "linked" data. Your questionnaire must reflect this, and your privacy policy must link to the data types.

Signing, fastlane match, and release keys

The deeper you get into multi-platform release, the more you appreciate a centralized signing story. Two patterns work for Flutter indies.

• Fastlane Match for iOS. Store your certificates in a private GitHub repo encrypted with a shared password. fastlane match provisions on every dev machine and every CI runner with one command. Kills "code signing" problems forever.
• Play App Signing for Android. Upload your app-signing key to Google Play, keep a second upload-signing key locally or in CI secret storage. You sign with the upload key, Play re-signs with the app-signing key per device.
• Secrets in CI. GitHub Actions encrypted secrets, Codemagic environment variables, Xcode Cloud secrets. Never commit key files to the repo.

CI/CD options for Flutter in 2026

Pick one, automate from green main to both stores. Running release commands manually is where rejection-worthy mistakes happen.

My default for a solo indie shipping their first Flutter app in 2026: Codemagic free tier until you outgrow the minutes. The Flutter-specific workflow steps save hours on the first iOS signing setup alone.

Top 10 rejection reasons in 2026 (and the fix)

1. targetSdk below 35 on Google Play. Bump it. Flutter 3.29+ makes this one line.
2. 16KB page alignment missing on Android. Upgrade NDK to 27+, rebuild.
3. Privacy manifest missing or inconsistent on iOS. Check the iOS privacy manifest guide and run your audit script.
4. Data Safety / App Privacy drift. Align the two questionnaires to the actual code.
5. Sign in with Apple missing when Google Sign-In is present on iOS. Add Sign in with Apple or remove Google Sign-In.
6. Crash on launch due to missing Firebase config.google-services.json and GoogleService-Info.plist must ship with the app on every platform you target.
7. Aggressive paywall during onboarding (iOS). Let the user experience value first. Apple has tightened review on paywall timing in 2026.
8. Broken deep links or web intents. Both stores now test these in review.
9. Outdated screenshots. 2023-era screenshot sizes are rejected. Use the 2026 required sizes listed above.
10. Placeholder content or Lorem ipsum left in. Still number one for both stores. Grep your codebase before every release.

The 48-hour release runbook

Print this and tick off each line for every release. It is what I use on every ship day, and it eliminates the common mistakes.

T minus 48 hours (Monday morning)

• Cut a release branch off main: git checkout -b release/1.4.0.
• Run the full test suite on CI. Fix anything flaky.
• Bump version in pubspec.yaml, android/app/build.gradle (as versionName and versionCode), and the iOS project.
• Generate a What's New string for both stores, translate to top five locales.
• Run flutter build appbundle --release and flutter build ipa --release.
• Run your privacy audit script.
• Upload TestFlight internal build.
• Upload Play Internal Testing build.

T minus 24 hours (Tuesday morning)

• Smoke test TestFlight build on iPhone 15 Pro and iPhone 12.
• Smoke test Play Internal build on Pixel 7 and a mid-tier Samsung.
• Run the full purchase flow in sandbox on both platforms.
• Run the full AI / signup / onboarding flow on both platforms.
• Verify Firebase Remote Config toggles behave.
• Check analytics events fire as expected in staging.

T minus 4 hours (Wednesday afternoon)

• Promote Play build from Internal to Production rollout (start at 10 percent).
• Submit iOS build for App Review with complete notes.
• Tag the release in git: git tag v1.4.0.
• Push tag: git push origin v1.4.0.
• Merge release branch back to main.

Post-launch (Thursday morning)

• Monitor crash-free rate in Sentry or Crashlytics. Threshold: hold above 99.5 percent.
• Check Play Console vitals: ANR rate, crash rate, slow rendering rate.
• Check App Store Connect metrics: crashes, load time.
• Respond to reviews on both stores.
• If stable at 24 hours, expand Play rollout to 50 percent; at 48 hours, 100 percent.

What The Flutter Kit ships

The Flutter Kit ships production-ready release configuration on both platforms. The android/app/build.gradle targets SDK 35, the NDK version is pinned to 27+, ProGuard rules are tuned, and a sample signing config is in place. The iOS side uses Xcode 26, ships the privacy manifest and the 2026 screenshot sizes as Fastlane snapshot templates, and the App Review notes template is prefilled for a typical indie launch.

A Codemagic workflow template is included that builds, tests, signs, and uploads both platforms on a tag push. $69 one-time, unlimited commercial projects. See every integration on the features page or jump to checkout. The Flutter Kit is specifically the option that does not leave release plumbing as an exercise for the reader.

Final recommendation

Most indie deployments fail at submission not because the app is bad but because a small platform requirement is missed. The fixes are individually 10 minutes of work. The aggregate is 90 minutes per platform. Build the muscle once, automate it, and every future release is a 15-minute dance rather than a panicked weekend.

If you are shipping your first Flutter release in 2026, give yourself two full days for the first launch. Use a boilerplate that starts you on the right target SDK, the right NDK, the right privacy manifest, and the right Codemagic workflow. The cost of inheriting correct defaults is always lower than the cost of learning them on submission day.