Last reviewed: November 2026
No Credit Card Required
Printed from checkflow.io/templates/product-development-launch/mobile-app-release-checklist
This free mobile app release checklist is for mobile leads, app developers, QA teams and product managers shipping one version of an app to the App Store, Google Play or both. One run covers one release, counted back from the planned release date. It sets the version and build numbers, cuts the release branch and sets the feature flags, runs regression on real devices and OS versions, and puts the build through TestFlight or Google Play testing with crash and performance checks against your release criteria. The store listing, screenshots and What’s New text are updated, the App Store privacy details and Google Play Data safety form match the build and its SDKs, and the age rating answers are reviewed. The review notes and a working test account go in before the release approver decides go or no-go. The build is submitted, any rejection is fixed, and the update rolls out in phases or stages while crashes and reviews are watched, with a pause and a fix if it goes wrong. It ends with replies to store reviews and a retrospective.
A mobile app release, in this template, is one version of one app going to the App Store, Google Play or both: the build, the tests on real devices, the beta, the store listing and privacy declarations, the store review and a gradual rollout to users. What makes it different from a web release is the store in the middle. Each store reviews the build before users can get it, its listing and privacy answers are part of the release, and a bad build cannot simply be rolled back: Apple lets you pause a phased release and Google lets you halt a staged rollout, but the fix goes out as a new build (Apple: phased release, Google: staged rollouts).
For releases without a store, the Software Release Management Checklist runs a versioned release train with its code freeze and go/no-go, and the Feature Release Process Checklist takes one feature through QA and staging. A back-end change the app depends on follows the Production Deployment & Rollback Checklist, a new service is checked once with the Production Readiness Review Checklist, and feedback beyond the store reviews belongs to the User Feedback Collection Checklist.
Covers: version and build numbers, the release branch and flags, regression on real devices, TestFlight and Google Play testing, the store listing, privacy details and Data safety form, age ratings, review access, submission, rejections and a phased or staged rollout.
Planned around: the planned release date.
Ends with: replies to store reviews and the release retrospective.
Covers: a versioned release train: scope, code freeze, release candidates, regression sign-offs, release notes, a go/no-go and the deploy.
Use it: for software that ships without a store review. Software Release Management Checklist.
Covers: one feature from its specification sign-off through code review, QA in staging and a go/no-go to production monitoring.
Use it: for each feature that later ships inside a mobile release. Feature Release Process Checklist.
Nine phases take one release from planning to the retrospective. The first task records the planned release date, which sets every due date, the people involved, and which stores the release goes to and whether it is the app’s first release there, so only those stores’ tasks appear. An update adds the upgrade test and the phased release or staged rollout; a first release adds the store set-up and, for a new personal Google Play account, production access. An app new on one store and already on the other gets each store’s own tasks. The go or no-go for submission in Phase 6 halts the checklist until the release approver decides.
Owned by the mobile lead. Enter the planned release date on the first task: every due date counts back from it in working days, and the rollout and follow-up tasks count forward. Choose the stores this release goes to, and whether it is the app’s first release there, so the checklist shows only the tasks for those stores.
The mobile lead fixes what is being built. Set the version and build numbers, cut the release branch at the code freeze, decide the feature flags, check signing, and upload the release candidate to each store.
The QA lead tests the release candidate on the devices and OS versions your users have. Apple’s guidelines ask for an app to be tested on-device for bugs and stability before it is submitted (2.1). Bugs found here are fixed on the release branch or deferred, and each fix means a new build.
The build goes to testers through TestFlight and Google Play’s testing tracks. The mobile lead collects feedback and crash reports, and the QA lead checks the beta against the release criteria before the final build is chosen.
The store listing owner updates what people see on each store, and the privacy reviewer makes the privacy declarations match what this build collects, including its third-party SDKs. The age rating answers are reviewed for anything this release changes.
Each store’s reviewers need to reach every part of the app. The mobile lead writes the review notes, the QA lead tests the review account from a clean install and checks every release criterion, and the release approver alone decides go or no-go. The checklist halts at the decision: nothing in submission or rollout can be completed until it is done.
The mobile lead submits the approved build to each store, held for the planned release date unless you choose automatic release. Each review outcome is recorded, and a rejection adds a task to fix it and submit again. The days allowed for review here are this template’s choice, not a store’s figure.
On the planned release date the approved versions go live: an update in phases on the App Store and as a staged rollout on Google Play, a first release to everyone. The mobile lead watches crashes and reviews, and decides with the release approver whether the rollout carries on or stops for a fix.
Once the release has reached everyone, the support lead replies to store reviews about it, any Google Play listing changes go live, the beta builds are expired, and the team looks back at the release.
As read on Apple’s and Google’s help pages on 3 November 2026 (Apple: Upcoming Requirements, Google: target API level, TestFlight, Google: testing requirements). Store rules change often: check each store’s pages on the day you release.
| Step | App Store (Apple) | Google Play | Phase |
|---|---|---|---|
| Build requirements | Built with Xcode 26 or later and an iOS 26 SDK (since 28 April 2026); iOS apps must target iOS 13 or later (since 9 September 2026) | New apps and app updates must target Android 16, API level 36 (from 31 August 2026; extensions could be requested to 1 November 2026) | 1 |
| Trader status | Declared in App Store Connect for the EU Digital Services Act; apps without it are removed from the App Store in the EU | Every account declares trader or non-trader under EEA and UK laws by 1 February 2027 | 1 |
| Beta testing | TestFlight: up to 100 internal and 10,000 external testers; the first build for external testers goes to App Review; builds last up to 90 days | Internal, closed and open testing tracks; a new personal account needs a closed test with at least 12 testers opted in for 14 days before production access | 4 and 6 |
| Privacy declaration | App privacy details in App Store Connect, including third-party partners’ practices | Data safety form, required for apps on closed, open and production tracks, even with no data collected | 5 |
| Account deletion | In the app, if the app supports account creation (guideline 5.1.1) | In the app and through a web link, if the app lets people create an account | 5 |
| Age rating | Age rating questions in App Store Connect, answered under Apple’s updated age rating system (due since 31 January 2026) | IARC content rating questionnaire, submitted again when content changes | 5 |
| Access for the reviewer | A demo account or full demo mode, back-end services live, and notes for non-obvious features (guideline 2.1) | Sign-in details on the App access page: always accessible, reusable, valid anywhere and in English | 6 |
| Gradual release | Phased release over 7 days for version updates (1%, 2%, 5%, 10%, 20%, 50%, 100%); pause for up to 30 days in total | Staged rollout for updates only; the percentage is raised by hand; halting stops new users receiving it | 7 and 8 |
| Replies to reviews | One public response per review, which may take up to 24 hours to appear | One public reply per review; the user gets a push notification and an email | 9 |
Every answer shows the shared tasks: planning, build, regression, beta, listing, privacy, the go or no-go, monitoring, reviews and the retrospective.
| Answer on the first task | What the checklist adds |
|---|---|
| iOS only, an update | The App Store tasks, the upgrade test and the phased release |
| Android only, an update | The Google Play tasks, the upgrade test, the staged rollout and the listing changes after 100% |
| iOS and Android, an update | Both stores’ tasks, the upgrade test, the phased release, the staged rollout and the listing changes after 100% |
| iOS only, a first release | The App Store tasks and the store set-up |
| Android only, a first release | The Google Play tasks, the store set-up and production access for a new personal account |
| iOS and Android, a first release | Both stores’ tasks, the store set-up and production access for a new personal account |
| iOS and Android, new on the App Store and an update on Google Play | Both stores’ tasks, the store set-up, the upgrade test, the staged rollout and the listing changes after 100% |
| iOS and Android, new on Google Play and an update on the App Store | Both stores’ tasks, the store set-up, production access for a new personal account, the upgrade test and the phased release |
The go or no-go is assigned to the release approver alone, and the checklist halts there: the submission and rollout tasks cannot be completed until the approver completes it. No-go adds a task before the decision to fix what stops the submission, so the approver can decide again once it is fixed.
Due dates count back from the planned release date in working days, so when the date moves after a rejection or a late bug, one change on the first task moves every step. Overdue alerts go to the people assigned, and the Reports Grid lists every release in progress with its answers, while Analytics shows where releases slow down.
One answer on the first task says which stores the release goes to and whether it is the app’s first release there. An iOS-only update never shows the Data safety form, and a first release never shows a phased release it cannot use. A rejection adds the task to fix it, and a stopped rollout adds the pause and the fix.
CheckFlow does not build, sign or upload your app, and it does not connect to App Store Connect or Play Console: the builds, testers, listings and rollouts stay there. CheckFlow makes sure every release gets the same checks in the same order, with an owner and a due date for each step, a recorded go or no-go before submission and a record of who did what and when.
Test each cycle with the QA Testing Checklist, follow each bug with the Bug Tracking & Resolution Checklist, and run the back end the app relies on through the Production Deployment & Rollback Checklist.
Software Release Management Checklist
QA Testing Checklist
Bug Tracking & Resolution Checklist
User Feedback Collection Checklist
Production Deployment & Rollback Checklist
Describe the process in a sentence and the AI checklist generator drafts the phases and tasks for you.
The version and build numbers, the release branch and feature flags, regression on real devices and OS versions, a beta through TestFlight or Google Play testing, crash and performance checks against your release criteria, the store listing, screenshots and What’s New text, the privacy declarations and age rating, review notes with a working test account, the go or no-go, submission and any rejection, a phased or staged rollout with monitoring, replies to reviews and a retrospective. This template covers each in nine phases.
A build made with the Xcode version and SDK Apple currently requires, the app tested on devices, the version’s metadata and screenshots, the app privacy details, the age rating answers, a privacy policy link, a declared EU trader status, and App Review information with a demo account if the app has a login, with the back end turned on. Apple’s guideline 2.1 asks for submissions to be final versions with all metadata and working links (App Review Guidelines).
Both release an update to a share of users first, and both are for updates only. Apple’s phased release runs over 7 days for users with automatic updates and can be paused for up to 30 days in total (Apple). Google Play’s staged rollout goes to the percentage you choose, which you raise by hand, and can be halted (Google). A first release goes to everyone on both stores.
The version does not reach users until the issue is fixed and the store reviews it again. Apple lets you reply to App Review with explanations and attachments, and a metadata rejection can go back with the same build (Apple). Google says a rejected update leaves the previous version available, and not to resubmit until every violation is fixed (Google). Both describe an appeal. In this template, a rejection adds a task to fix it and resubmit.
Both tell people on the store what data the app collects and how it is used, and both must include data collected by third-party SDKs. Apple’s app privacy details are answered in App Store Connect and shown on the product page. Google’s Data safety form is completed in Play Console, reviewed as part of app review, and needed even when an app collects no data. This template has one task for each and an SDK list both rely on.
Personal accounts created after 13 November 2023 do. Google requires a closed test with at least 12 testers who have been opted in continuously for the last 14 days before you can apply for production access (Play Console Help). Google’s requirement is written for personal accounts created after that date; it does not name organisation accounts. In this template the step appears for a first Google Play release; mark it not applicable if your account is not covered.
Turn the feature off with a flag if you can, which needs no store review. Otherwise pause Apple’s phased release in App Store Connect and halt the staged rollout in Play Console, so no more users receive the version. Users who already have it keep it, so the fix goes out as a new build that passes review again. In this template, Stop on the rollout decision adds the pause and the fix tasks.
In this template the mobile lead owns the release from planning to the retrospective. A QA lead runs the regression and the beta checks, a store listing owner looks after the text, screenshots and age rating answers, a privacy reviewer keeps the privacy declarations accurate, a support lead briefs support and replies to store reviews, and a release approver alone decides go or no-go for submission. One person can hold several of these roles.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
14-day free trial, no credit cardFull refund in your first 30 daysUS hosting, EU on request
