Mobile App Release Checklist

An app release checklist for iOS and Android: build numbers, signing, store listing, privacy forms, review submission, staged rollout and crash monitoring.

Typical schedule per app release
The checklist 5 sections, 22 items
Variables {{app_name}} {{version}}
Start from CI

Use this template Free, no credit card. Imports the checklist into your Runbook organization.

Use this checklist for every iOS and Android release that goes to the public stores. Mobile releases are different from web deploys: you cannot roll back a version people have already installed, store review adds a delay you do not control, and old app versions stay in use for months. That makes the steps before submission and the staged rollout much more important.

Who owns it

A release owner, usually a mobile engineer, owns the run. Product or marketing owns the store listing text and screenshots. Someone with access to App Store Connect and Google Play Console must be available on release day to answer review questions or pause a rollout.

Common pitfalls

Assuming you can roll back. You can only ship a new version. Keep a kill switch or remote config for risky features, so you can turn them off without a new build.
Breaking older app versions. Your backend must keep supporting the versions still in use. Check API changes against the oldest version you support, and plan a forced-update screen if needed.
Missing crash symbols. Without dSYM files for iOS and mapping files for Android, crash reports are unreadable. Upload them as part of the build.
Outdated privacy answers. Adding an analytics or ads SDK changes what the app collects. Update the App Store privacy details and the Google Play Data safety form to match.
Releasing to everyone at once. Use phased release on iOS and staged rollout on Android, and watch crash rates before you widen it.

The checklist: Release {{app_name}} {{version}} to the app stores

Build

Version {{version}} and new build numbers are set for iOS and Android
Both stores reject a build number that has been used before.
Release builds are signed with the production certificates and keys
Builds point to the production API and have debug menus and test flags turned off
Crash symbol files (dSYM for iOS, mapping file for Android) are uploaded to your crash reporter
Android build meets the current Google Play target API level requirement

Test

Regression test passes on a set of real devices, including the oldest supported OS versions
Upgrade from the previous store version keeps user data and login
Beta build tested through TestFlight and a Play testing track by internal testers
Backend changes are compatible with the older app versions still in use
Push notifications, deep links and in-app purchases work in the release build optional

Store listing and compliance

What's new text for {{version}} is written for both stores
Screenshots and store descriptions are updated for changed features optional
App Store privacy details and Google Play Data safety form match what the app collects
Demo account and review notes are provided for features behind a login

Submit and roll out

iOS build is submitted for App Review with phased release turned on
Android build is released to production as a staged rollout
Crash-free rate and reviews are checked before the rollout is widened
Rollout is paused if crashes or a serious bug appear, and a fix is planned

After release

Rollout of {{version}} is completed to all users on both platforms
Support team knows about the release and any known issues
Minimum supported app version is raised in remote config if old versions must update optional
Release is tagged in Git and the changelog is updated

Checklist as Markdown

# Release {{app_name}} {{version}} to the app stores

## Build
- [ ] Version {{version}} and new build numbers are set for iOS and Android
  Both stores reject a build number that has been used before.
- [ ] Release builds are signed with the production certificates and keys
- [ ] Builds point to the production API and have debug menus and test flags turned off
- [ ] Crash symbol files (dSYM for iOS, mapping file for Android) are uploaded to your crash reporter
- [ ] Android build meets the current Google Play target API level requirement

## Test
- [ ] Regression test passes on a set of real devices, including the oldest supported OS versions
- [ ] Upgrade from the previous store version keeps user data and login
- [ ] Beta build tested through TestFlight and a Play testing track by internal testers
- [ ] Backend changes are compatible with the older app versions still in use
- [ ] Push notifications, deep links and in-app purchases work in the release build (optional)

## Store listing and compliance
- [ ] What's new text for {{version}} is written for both stores
- [ ] Screenshots and store descriptions are updated for changed features (optional)
- [ ] App Store privacy details and Google Play Data safety form match what the app collects
- [ ] Demo account and review notes are provided for features behind a login

## Submit and roll out
- [ ] iOS build is submitted for App Review with phased release turned on
- [ ] Android build is released to production as a staged rollout
- [ ] Crash-free rate and reviews are checked before the rollout is widened
- [ ] Rollout is paused if crashes or a serious bug appear, and a fix is planned

## After release
- [ ] Rollout of {{version}} is completed to all users on both platforms
- [ ] Support team knows about the release and any known issues
- [ ] Minimum supported app version is raised in remote config if old versions must update (optional)
- [ ] Release is tagged in Git and the changelog is updated

Start this checklist from your pipeline

When the release build is uploaded to TestFlight and Play Console, POST /api/v1/runs with template "Release {{app_name}} {{version}} to the app stores".

curl -X POST https://runbook.metastic.ch/api/v1/runs \
  -H "Authorization: Bearer $RUNBOOK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"template": "Release {{app_name}} {{version}} to the app stores", "variables": {"app_name": "…", "version": "…"}}'

See the API and the GitHub Action

Frequently asked questions

How long does App Store review take?

It varies. Many reviews finish within a day or two, but rejections and questions add more time, and review can be slower around holidays. Plan your release date with some buffer, and do not promise customers an exact day for an iOS release.

What is the difference between a phased release and a staged rollout?

They are the names Apple and Google use for releasing an update to a growing share of users. On iOS, phased release applies to automatic updates over several days, and you can pause it. On Android, you choose the share of users yourself in Play Console and can increase it, pause it or halt it.

Can I roll back a mobile app release?

Not in the way you roll back a web deploy. Users who installed the version keep it. You can halt a staged rollout on Android, pause a phased release on iOS and turn off features through remote config. To fix a bug for everyone you need a new build with a higher build number.

Updated 2026-11-04