App Store / Google Play / Flutter

Flutter App Release Checklist (2026): What Ten Apple Rejections Taught Me

PEAKSTW is a real cross-platform app that I developed, submitted, and still operate. Ten Apple review rejections did not teach me how to predict a reviewer. They taught me to put accounts, subscriptions, review access, real devices, backend state, and release evidence into one gate before pressing Submit.

August 13, 2026 · 13 minute read · Printable checklist

Two dated requirements to check first

Some submission failures happen before review begins because the uploaded build no longer meets a platform floor. These requirements are time-sensitive and should stay at the top of the release ticket:

• Apple: Since April 28, 2026, App Store Connect uploads must be built with Xcode 26 or later and the corresponding iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26 SDK. Confirm the current minimum on Apple’s Upcoming Requirements page rather than relying on an old CI image.
• Google Play: Starting August 31, 2026, mobile new apps and app updates must target Android 16, API level 36, or higher. Platform-specific exceptions exist for Wear OS, Android Automotive OS, Android TV, and Android XR. Google’s target API guide is the source of truth for exact levels, availability rules, and extensions.

For a Flutter app, an SDK bump is not merely a number change. Rebuild and exercise permissions, background work, notifications, billing, file access, edge-to-edge layout, and every native plugin that crosses the platform boundary.

The 15-minute pre-submission pass

• The selected build is the release candidate: no crash, placeholder, staging URL, debug menu, or unfinished route.
• The required Xcode and target API floors are satisfied by the actual uploaded binary, not only by a local config file.
• Production APIs, images, authentication, email, and third-party services are reachable from a clean public network.
• Review Notes explain every non-obvious step. If sign-in is required, the reviewer has a durable demo account or a complete demo mode.
• Store copy, screenshots, privacy policy, support URL, age rating, Data safety answers, and visible app behavior agree.
• If the app creates accounts, account deletion can be initiated inside the app; deactivation, logout, or a support email is not presented as deletion.
• Google Play’s Data safety form includes a working web deletion resource for users who uninstalled the app.
• If a third-party or social login authenticates the primary account, Apple Guideline 4.8 and its exceptions were checked for this exact use case.
• Every subscription and in-app product is complete, available in the intended storefronts, and displayed with store-returned localized pricing.
• Purchase, cancel, pending, restore, renewal, expiry, refund, revocation, upgrade, and downgrade paths were exercised.
• Apple App Store Server Notifications V2 and Google Real-time developer notifications reached the production backend, and test events changed only the intended entitlement.
• At least one physical iPhone and one physical Android device covered sign-in, denied permissions, offline recovery, background/foreground transitions, and reinstall.
• The release evidence pack records the commit, version, build number, signed artifact, test results, screen capture, review credentials, backend health, and rollback path.

1. Accounts and privacy: functional is not policy-complete

Account deletion is a lifecycle, not a button

Apple’s App Review Guidelines say that an app supporting account creation must also offer account deletion within the app. Apple’s dedicated account deletion guidance distinguishes deletion from temporary deactivation and explains additional considerations for Sign in with Apple and active subscriptions.

Google Play adds an off-device requirement. Its User Data policy guidance requires an in-app deletion path and a web resource entered in the Data safety form so a person who has uninstalled the app can still request deletion.

• Place deletion in an intuitive account or privacy screen. Reasonable identity verification is fine; intentional friction is not.
• Explain which data is deleted, the processing period, and which records must be retained for security, fraud prevention, or law.
• If deleting an account does not cancel an App Store or Play subscription, disclose that before confirmation and give a direct management path.
• If Sign in with Apple was used, include token revocation in the deletion design rather than deleting only your database row.
• Test idempotency: a retry, delayed job, or repeated callback must not corrupt shared records or recreate the account.
• Keep privacy policy language consistent across the store listing, app, deletion page, retention job, and support response.

Third-party sign-in depends on equivalent capabilities and exceptions

Apple Guideline 4.8 applies when a third-party or social login service authenticates the app’s primary account. The guideline describes an equivalent login option with data-minimization and privacy characteristics, and it also lists exceptions such as certain enterprise, education, business, government, or industry-backed identity systems. Do not mechanically add a button because an old blog post says “Google login always requires Apple login.” Read the current guideline and map your actual account flow to the rule or an exception.

2. Subscriptions: verify entitlements, not only checkout

Store billing has at least four layers. A green purchase sheet proves only one of them:

The Google Play productId trap

Google Play’s current subscription model lets one subscription product contain more than one base plan and offer. A monthly plan, annual plan, free trial, and win-back offer do not necessarily have separate product IDs. Code that treats productId as the only price-plan key can collapse distinct choices or grant the wrong entitlement.

• Map the product, base plan, offer token, billing period, and entitlement explicitly.
• Query the currently eligible offers before display. Google’s Billing Library integration guide advises against caching stale ProductDetails objects.
• Show the current plan, destination plan, price, billing period, and effective date during an upgrade or downgrade.
• Test ineligible and stale-offer behavior. Do not assume every returned offer remains purchasable.
• Use server-verified store state as the entitlement authority; notifications trigger synchronization but are not a complete subscription record.

Notifications say “something changed,” then you fetch truth

Google’s RTDN reference says that a notification reports a purchase-state change but does not carry the full purchase status; the backend must call the Google Play Developer API. Apple provides App Store Server Notifications V2 and the App Store Server API for transaction and subscription state. Test the handler, not just the URL: validate signatures, associate the correct user, tolerate retries, handle event ordering, reconcile missed events, and retain enough evidence to explain an entitlement change.

3. Test store behavior across environments

Local mocks are useful, but they do not prove the store-facing configuration or server path. Apple’s StoreKit testing guide separates Xcode testing, Sandbox, and TestFlight. It explicitly includes restores, subscription offers, renewals, refunds, revocations, cancellation, and expiry scenarios. Google recommends license testers and Play Billing Lab in its billing test guide, including declined, delayed, pending, and chargeback-like paths.

• Run fast deterministic cases locally, then repeat store-integrated cases through Sandbox/TestFlight and Play test tracks.
• Confirm the tester account actually controls the purchase. Multiple Google Accounts on one device can change which account pays.
• Exercise “always declines” and delayed payment instruments; grant access only after the purchase becomes complete.
• Test with a non-license account occasionally or after a major billing change so tester-specific behavior does not become an accidental dependency.
• Capture both client logs and server entitlement history for each test identity without placing credentials in the evidence pack.

4. Review access: do not make the reviewer reverse-engineer your product

Apple’s submission overview points developers to App Review information for context that helps the review team. A core flow hidden behind a short-lived OTP, company VPN, empty account, location condition, or undocumented hardware dependency is not review-ready simply because it works for the developer.

• Use a durable review account that does not depend on the developer’s phone and will not expire during review.
• Seed representative data so the reviewer can see the product value instead of an empty dashboard.
• Describe each non-obvious step, feature flag, permission, sample record, and subscription entry point in Review Notes.
• If a flow requires a location, accessory, physical action, or scheduled event, provide a short video and an alternative review route where permitted.
• Open every support, privacy, deletion, and backend URL from a clean logged-out network without a company VPN.
• Keep a secure internal record of the review credential owner and expiry; never publish credentials in source control or documentation.

5. Real-device and cross-platform boundaries

A Flutter test suite can prove Dart behavior and still miss native configuration, store identity, OS lifecycle, signing, permission, or plugin failures. The release candidate should survive the boundaries the stores and users actually exercise:

• Run both a clean install and an upgrade from the last public version; a failed migration must not trap the app on launch.
• Deny location, camera, notifications, photos, and tracking where applicable; offer a usable fallback or a clear recovery path.
• Disable the network, background and terminate the app, restore connectivity, and verify that queued operations do not duplicate.
• Increase system text size, test small screens and keyboard overlap, and confirm that primary controls remain visible and operable.
• Log out, delete the account, expire the subscription, revoke a purchase, and reinstall; cached data and paid access must follow current server state.
• Install from TestFlight or a Google Play testing track. A locally installed debug build does not cover store delivery or signing.
• Confirm app links, universal links, notifications, background modes, keychain/keystore access, and deep-link routing in release mode.

6. Google’s 12 testers / 14 days rule has a scope

Google’s current testing requirement applies to personal developer accounts created after November 13, 2023. Before applying for production access, the app needs a closed test with at least 12 testers continuously opted in for at least 14 days. The developer then answers questions about testing, feedback, changes, and production readiness.

• Confirm the account type and creation date before applying this gate. Do not tell every organization or older personal account that the same rule applies.
• Track each tester’s opt-in date and actual participation; a person leaving can affect the continuous-duration requirement.
• Give testers core journeys and collect useful device, build, result, and issue information instead of recruiting names only.
• Use internal testing first for rapid build and installation checks, even though it does not replace the required closed-test period.
• Answer the production-access questions from saved evidence rather than reconstructing two weeks of testing from memory.

7. Turn “submitted” into an auditable release gate

After ten rejection rounds, the most expensive pattern was fixing one symptom, resubmitting immediately, and discovering an old neighboring problem in the next round. I now inspect each risk family together and save runtime evidence before submission:

• Artifact identity: commit, version, build number, signing identity, store record, and uploaded binary describe the same release.
• Policy evidence: links and access dates for every platform rule that materially shaped the implementation.
• Behavior evidence: test case, device, OS, account type, screen capture, server event, and observed result.
• Production evidence: public API, authentication, notification endpoint, privacy page, deletion page, and support route are reachable and return the intended content.
• Recovery evidence: feature flag, previous build, data-compatibility boundary, contact owner, and rollback decision are known.

A successful upload is therefore submitted, not approved. A passing checklist is release eligibility, not traffic. Until analytics access exists, downloads, store impressions, page views, and conversions remain not measured; do not infer them from a green CI job, accepted binary, valid feed, or social reactions.

What this checklist cannot guarantee

It cannot guarantee first-pass approval. It cannot replace the current App Review Guidelines, Google Play policy, legal advice, or requirements for regulated categories such as health and finance. Storefront, app category, data types, commerce model, hardware, and regional rules can add obligations. What the checklist does guarantee is a better incident record: you know which artifact was submitted, what was tested, which policy interpretation was used, and what changed after review.

To remove the items that do not apply to your release, use the free 2026 App Release Checklist Generator. It filters by store, first launch or update, account features, and purchases, then exports the result as Markdown. For a broader evidence contract, continue with the AI Agent Production Readiness Checklist or the production readiness tool.