My App Store and Google Play Release Checklist for Flutter Apps

Writing the app is the part you plan for. Getting it through two different review processes, with two different privacy forms, signing systems and sets of rules, is the part that surprises people. It’s usually where a “we launch Friday” plan slips to the following Thursday.

Across the 15+ apps I’ve shipped, I’ve learned that review problems rarely come from the code. They come from a missing demo account, a privacy answer that doesn’t match what the app actually does, or a forgotten account deletion button.

So I keep a checklist. Here it is, roughly in the order I go through it.

1. Versioning and build numbers

In Flutter, both platforms read the version from pubspec.yaml:

version: 2.3.0+41

The part before the + is the user-visible version (CFBundleShortVersionString on iOS, versionName on Android). The part after it is the build number (CFBundleVersion / versionCode).

The rules that matter:

• The build number must increase with every upload. Both stores reject reused build numbers, even for a build that never went live.
• Bump the user-facing version according to what changed, and keep both platforms on the same version so support conversations stay simple.
• In CI, I generate the build number from the pipeline run instead of editing it by hand. You can override it at build time:

flutter build appbundle --release --build-number=$BUILD_ID
flutter build ipa --release --build-number=$BUILD_ID

I describe the pipeline side in Flutter CI/CD with Azure DevOps.

2. Signing

Android: use Play App Signing. Google holds the key that signs what users install, and you sign uploads with a separate upload key. If you lose the upload key, Google can reset it. If you lose a self-managed app signing key, you can never update the app again.

Keep the upload keystore and its key.properties file out of git. Store them in your CI secure files and back them up somewhere you’ll still be able to find in two years.

iOS: a Distribution certificate plus an App Store provisioning profile. Automatic signing in Xcode handles this for most teams. For CI, use an App Store Connect API key rather than a personal Apple ID login.

3. Platform requirements

Both stores raise their minimum requirements every year, and an outdated build simply gets rejected at upload:

• Google Play requires a recent targetSdkVersion. Since August 31, 2025, new apps and updates must target Android 15 (API level 35). Check what the current Flutter template sets, and test the behavior changes that come with each new target level.
• App Store requires builds made with a recent Xcode and iOS SDK. Keep your build machine or CI image up to date.

Look up the current deadlines each year. They move on a predictable annual schedule.

4. Privacy: the forms have to match reality

This is the area where I see the most rejections, and it’s the least technical part of the release.

• Privacy policy URL. Both stores require one, and it has to be a real, reachable page that describes your app, not a generic template.
• App Store privacy “nutrition labels” in App Store Connect: declare what data you collect, whether it’s linked to the user, and whether it’s used for tracking.
• Google Play Data safety form: a similar declaration with a slightly different vocabulary.
• iOS privacy manifest (PrivacyInfo.xcprivacy): declares the data your app collects and the reasons it uses certain system APIs (such as UserDefaults or file timestamps). Many plugins ship their own manifests, so keep your dependencies up to date.

The trap is third-party SDKs. Analytics, crash reporting and especially ad SDKs collect data your own code never touches, and it all has to be declared. An app like SafeMom, which integrates Facebook and TikTok ad SDKs, is exactly where this matters: every SDK’s data collection has to be reviewed and declared, not treated as an afterthought. More on that in ad monetization without ruining UX.

5. Account deletion

If users can create an account in your app, both stores require that they can delete it:

• Apple requires account deletion to be possible from inside the app, not just “email us”.
• Google Play requires an in-app path and a web link where users can request deletion without reinstalling the app. You enter that URL in the Data safety section.

Deletion should actually delete the account (or anonymize it, within legal retention limits), and the user should be told what happens to their data. Plan for it on the backend from the start. Adding it the week before launch is painful.

6. Help the reviewer

Reviewers are people working through a queue. Make their job easy:

• A working demo account in the review notes, with data already in it. An empty app with no content looks broken.
• Notes for anything unusual: hardware the app needs, features that only work in certain regions, how to reach a paywalled screen.
• A demo video if a flow is hard to reach, such as CarPlay or a physical device pairing.

7. The usual rejections

Guideline	What it’s about	How I avoid it
2.1 App Completeness	Crashes, broken links, placeholder content, a demo login that doesn’t work	Test the release build end to end on a real device, and log in with the demo account yourself
4.0 Design (incl. 4.2 Minimum Functionality)	Apps that feel like a wrapped website or too thin to justify an app	Use native navigation patterns and give the app real functionality
5.1.1 Data Collection and Storage	Unnecessary permissions, unclear purpose strings, required sign-up for no reason, no account deletion	Ask permissions in context, write specific purpose strings, add deletion
3.1.1 In-App Purchase	Selling digital content or features without Apple’s in-app purchase	Use StoreKit (or RevenueCat on top of it) for digital goods; physical goods and services can use Stripe

The 3.1.1 line matters for marketplace apps. Range Buddy uses Stripe Connect for multi-party payments and RevenueCat for in-app subscriptions. The rule of thumb behind that kind of split: digital features unlocked in the app go through the store’s in-app purchase, while payments for real-world goods and services can use a provider like Stripe.

Google Play’s review is more automated, but policy violations, especially around permissions and data safety mismatches, can lead to rejections or removals after release.

8. Store listing

• Screenshots for every required device size, showing the real app. On iOS, a 6.9“ iPhone set (and an iPad set if you support iPad) covers the minimum.
• A first screenshot that explains the app’s value without needing the description.
• A short description and keywords written for people searching, not for the marketing team.

9. Test before you go live

• TestFlight for iOS: internal testers get builds almost immediately. External testers need a short beta review.
• Play internal testing for fast distribution to your team, then closed testing for wider groups. New personal developer accounts on Google Play must run a closed test with a minimum number of testers for a set period before they can publish to production, so build that into your timeline.

10. Roll out gradually

Never release to 100% on day one:

• App Store phased release spreads an automatic update over seven days, and you can pause it.
• Google Play staged rollout lets you choose the percentage and increase it as confidence grows.

This only helps if you’re watching. Crash reporting should be live before the release, not added after the first one-star review. I cover my setup in crash reporting and monitoring in Flutter. Check crash-free sessions and new crash clusters daily during a rollout, and pause it if something looks wrong.

Takeaways

• Increase the build number on every upload, and automate it in CI.
• Use Play App Signing, and guard your upload key and iOS credentials like production secrets.
• Make privacy labels, the Data safety form and the privacy manifest match what the app and its SDKs actually do.
• Ship account deletion in the app, plus a web deletion link for Google Play.
• Give reviewers a working demo account and clear notes.
• Roll out in stages with crash reporting already running.

If you have an app that’s nearly ready and want help getting it through both stores, get in touch.