App release checklist for iOS and Android updates

An app release checklist for updates covers four stages: before you submit, while the stores review it, during the rollout, and after it reaches everyone. Many checklists online are written for a first launch. This one is for the release you ship every few weeks, where a stale demo login, a missing symbol upload, or a rollout nobody is watching can cost you days. Copy the template at the end and cut it down to fit.

The steps follow Apple's and Google's documentation. We did not test them on a live release, so check the current console screens as you go.

Before you submit

Start with the build, because everything else depends on it.

• Version and build numbers are raised, with an Android version code higher than anything you've uploaded.
• The release has a Git tag, and you've compared it against the last release.
• Migrations are checked by upgrading from the previous version on a real device, with real data.
• The Xcode version and target SDK meet the current store requirements. An out-of-date setup can lead to an Invalid Binary status.
• Debug endpoints, test flags, and logging are off in the release build.
• Risky features sit behind a flag that you can turn off from the server.

Then test the actual binary:

• The exact build is installed from TestFlight and a Google Play test track, on a clean device.
• The main flows pass, on your oldest supported OS and on a small screen.
• A test crash reaches your crash tool with a readable stack trace. Upload dSYMs and Android mapping files.
• The release name in your crash tool matches your naming rule. See Sentry release not showing data.

Then check what reviewers and users will see:

• The demo account works, and it won't expire during review. Apple asks for this in guideline 2.1.
• Notes for App Review explain anything that a reviewer can't reach on their own.
• Privacy policy, support, and marketing URLs open.
• Store screenshots still match the app.
• App privacy and data safety declarations reflect any new SDKs.
• Release notes are written and fit the limits: 4,000 characters on the App Store and 500 per language on Google Play.
• Export compliance is answered, or set in the Info.plist.

During review

• Choose how the release goes out before approval. Manual release on iOS, or managed publishing on Google Play, lets you pick the moment.
• Turn on phased release, or plan your staged rollout percentages.
• Confirm on Publishing overview that your Android changes were sent for review.
• Keep someone with the right role available to reply to App Review.
• Avoid other store changes that could add to the review queue.
• Tell support which version is coming and roughly when. Allow for Apple's and Google's review times.

During rollout

• Confirm that the release actually went out. Check the status, then open the store listing on a device.
• Name a daily owner. iOS moves forward on its own, and Android waits for someone to raise it.
• Compare release health to the previous version at each step.
• Read new crash issues by the number of users affected, and check Android vitals.
• Read support tickets and new store reviews.
• Agree on what would make you pause. Our post-deployment checklist covers the signals to watch.
• Have a fix plan ready. The App Store has no rollback button, so know how you'd ship an urgent fix.

After release

• Record when the rollout reached 100%.
• Check adoption, and decide when older versions can be dropped.
• Update your minimum supported version, if your app enforces one.
• Close the release with a short note about what went well and what you'd change.
• Change this checklist if something surprised you.

Copyable template

# Release: [app] [version] ([build])
Owner: ______  Backup: ______  Target date: ______

## Before submit
- [ ] Version/build raised, tag created, diff reviewed
- [ ] Upgrade tested from previous version
- [ ] SDK and Xcode requirements met
- [ ] Flags set for risky features
- [ ] Exact build tested on a clean device
- [ ] Test crash readable in crash tool
- [ ] Demo account works
- [ ] URLs, screenshots, privacy info current
- [ ] Release notes written

## In review
- [ ] Release option chosen
- [ ] Phased/staged plan set
- [ ] Android changes sent for review
- [ ] Someone can reply to App Review
- [ ] Support told

## Rollout
- [ ] Live on device (iOS / Android)
- [ ] Daily owner named
- [ ] Pause rule: ______
- [ ] Day-by-day health check done

## After
- [ ] 100% date recorded
- [ ] Adoption checked
- [ ] Notes filed

How to keep an app release checklist useful

A checklist only helps if it gets used. Keep it in the place where your releases already live, such as your issue tracker, so that each release gets its own copy. Assign one owner, since a shared checklist is easily assumed to be someone else's.

Cut anything that never catches a problem. Add a line after each surprise. After a few releases, this list will fit your app far better than it fits anyone else's.

For agencies

Keep one template for all your clients and a short per-client section on top: who owns the account, who approves store notes, and where the demo login lives. When a client's Account Holder is hard to reach, note that too. Agreements and transfers can stall on them.

Specita keeps one record per release across iOS, Android, web, and API, with source changes and reported deliveries attached, and it can deliver a release brief to Slack or email. See getting started.

Apple and Google guidance checked on November 4, 2026.