Mobile app release checklist template and release blockers

A web team that ships a bad release can usually deploy the previous version within minutes. A mobile team cannot. Once a build is installed on a phone, it stays there until the user updates it, and an update may need another round of store review. A missed step before release can become a bug users live with for days.

That is why most mobile teams end up with a release checklist. This guide gives a practical template for taking iOS and Android builds from beta to production, explains how to handle release blockers, and shows how to tie both to the step that ships the build, including how this works in AppForShare.

Why mobile releases need a checklist

Three things make mobile releases harder to undo than web releases.

• No instant rollback for installed apps. You can stop a staged rollout or replace a download link, but you cannot reach into a phone and swap the build that is already installed. Users who updated keep the broken version until a fix arrives and they install it.
• Store review adds delay. A fix for iOS goes through App Review again, and Google Play reviews updates too. Review times vary, so a hotfix is never instant.
• Two platforms, two sets of rules. iOS and Android have different signing, different version numbers, different store forms and different devices. A step that is done on one platform is easy to forget on the other.

A checklist turns the things a careful developer remembers into things the whole team can see. But a checklist only helps if it is used every time. A document people open when they remember is a reminder, not a check. It works when the release cannot go out until it is done, or when skipping it leaves a visible record.

A mobile app release checklist template

The list below covers the common steps between a beta build and a production release on both platforms. Trim it to what your team actually does. A checklist that is too long gets ticked without reading.

Build and signing

• The release build is made from the tagged commit on the release branch, not from a local machine with uncommitted changes.
• Version and build numbers are set: the iOS version and build number, the Android versionName and versionCode, each higher than the last release.
• iOS is signed with the distribution certificate and the right provisioning profile for the target (App Store, ad hoc or enterprise).
• Android is signed with the release key or uploaded for Play App Signing, and the upload key is the one on file.
• Debug flags, test endpoints and verbose logging are off. The build points at production services.
• Android targets the API level Google Play currently requires for updates.

Testing

• The main flows pass on this exact build: sign up, sign in, the core action of the app and payment if there is one.
• Upgrade from the previous production version works, with existing data and a signed in user.
• The build has been tested on the oldest supported OS version and on at least one small screen on each platform.
• Crash reporting is enabled and the beta shows no new crash on a main flow.
• Every tester report marked as a release blocker is resolved.
• QA sign off is recorded: the person who signed off and the build they tested.

Store and compliance

• The App Store privacy details and the Google Play data safety form match what this version actually collects, including new SDKs.
• Screenshots and the store description reflect the current version where features changed.
• Export compliance is answered for iOS (encryption use).
• Permission prompts have clear purpose strings, and new permissions are explained in the listing or review notes.
• Review notes include a working demo account if the app needs sign in.

Communication

• Release notes are written for users, not as a commit log.
• Support and the client, if there is one, know what is changing and when.
• The rollout plan is agreed: phased release on iOS, staged rollout percentage on Android, and who watches crash reports in the first days.

That is 20 items. For store specific detail, the App Store submission checklist goes deeper on the iOS side, and the Google Play staged rollout guide covers the Android rollout step.

Release blockers: what they are and how to handle them

A release blocker is a known problem serious enough that the build should not ship until it is fixed. The checklist covers steps you do. Blockers cover problems you find. A release needs both: every step done and no open blockers.

What counts as a blocker

Each team sets its own rule, and it helps to write it down before the pressure of a release date. A rule that works for many teams: data loss, crashes on a main flow, blocked sign in or payment, a broken upgrade from the previous version, and anything that would break a store rule are blockers. Layout problems, wording, and rare edge cases with a workaround usually are not. They get fixed in the next release.

Who decides

Anyone can suggest that a report is a blocker. One person, usually the release owner or the QA lead, makes the call. Without an owner, blockers either pile up or quietly disappear.

How to triage

Decide on each new report as soon as it arrives: blocker or not. Ask two questions. Would a user notice this in normal use? Would it cost them data, money or access? If either answer is yes and there is no easy workaround, treat it as a blocker. Recheck old reports on the newest build. Our guide to collecting tester feedback with screenshots covers the report itself and the triage routine in more detail.

Resolving blockers

A blocker is resolved when the fix is in a new build and someone has checked it on that build, or when the owner decides with a short note that it is not a blocker after all. Moving it to the next release is fine, as long as the decision is written down.

Gate on zero open blockers

The release rule is simple: the number of open blockers for the app must be zero. Count blockers per app, not per build. A blocker reported on last week's build still applies to today's build until someone confirms it is fixed.

Gate the step that ships

A checklist and a blocker list help most when they are attached to the step that ships the build, so that the release cannot happen without them. For a team that shares builds through a production download link, that step is putting the build into the Live channel. For a store release, it is submitting or promoting the build.

Two rules make a gate work in practice.

• Every route gets the same answer. If the dashboard blocks the release but a CI job or a script can still push the build, the gate is only a suggestion. The build page, the CLI and the CI pipeline should all check the same list.
• Emergencies have an override, and the override is recorded. Sometimes a fix has to go out before every step is done. A gate with no override gets switched off the first time that happens. Let a senior person put the build in anyway, and record who did it, so the team can see later what was skipped and why.

How the release checklist works in AppForShare

AppForShare shares iOS and Android builds through install links and channel links, such as a Beta and a Live channel per app. The release checklist is part of the Team plan and guards the Live channel.

One checklist, ticked per build

An Admin writes one release checklist for the workspace, up to 20 steps, in Dashboard, Settings. Each build then has its own ticks on its build page, and each tick shows who ticked it and when. Developers tick steps; only Admins can edit the checklist itself.

The gate

The Admin chooses which channel the checklist guards: Live by default, or none. That channel only takes a build when every step is ticked and, if the blocker check is switched on, no release blocker is open in that app. Blockers are tester feedback reports the team marked as release blockers. Testers send those reports with screenshots from the install page, with no SDK in the app, on every plan; marking a report as a blocker is a Team feature. A blocker reported on an older build of the same app still counts until it is resolved.

The answer is the same whichever way the build is promoted: from the build page, the CLI, the GitHub Action or the MCP server. An upload with --channel live for a build that is not ready still uploads; it just skips the channel. See Beta and Live channels for how channel links work.

Override for emergencies

An Admin can put a build into the channel anyway. The channel row on the build page then shows who did it, for example "put in by Sara before the release checklist was done". The MCP server never overrides, so an AI assistant cannot skip the checklist for you.

If the workspace moves below the Team plan, the gate stops holding channels back.

CLI and MCP

From a terminal or a CI job:

npx appforshare checklist <build>
npx appforshare promote <build> --channel live

The first command shows the steps, the open blockers and whether the gate would take the build. The second promotes the build, and an Admin token can add --force to override. Setup for pipelines is in the CI docs.

The MCP server has two tools: release_checklist reads the checklist and gate status for a build, and tick_release_step ticks a step after asking for confirmation.

What it does not do

• The gate guards the AppForShare Live channel link. It does not send anything to the App Store or Google Play, and store submissions are not held back by it.
• It does not test the build. The ticks record that a person did the step. To decide what to test, the AI test plan writes a list from what changed in the build.

The release checklist and release blockers are on Team; see pricing for what each plan includes.

Common questions

What should a mobile app release checklist include?

At minimum: version and build numbers, release signing, production configuration, main flow and upgrade tests on the exact build, zero open blockers, store privacy forms that match the app, release notes, and an agreed rollout plan.

What is a release blocker?

A known problem serious enough that the build should not ship until it is fixed, such as data loss, a crash on a main flow, blocked sign in or payment, or a broken upgrade. Your team sets the exact rule, and one person makes the call on each report.

How do I record QA sign off before a release?

Record who signed off and which build they tested, not just that testing happened. In AppForShare, a sign off step in the release checklist shows who ticked it and when, on the page of that build.

Can we still release in an emergency if the checklist is not done?

In AppForShare, an Admin can put the build into the Live channel anyway, from the build page or with --force on an Admin token. The channel row records who did it. The MCP server cannot override.

Does the release checklist stop App Store or Google Play releases?

No. It guards the AppForShare channel it is set on, Live by default. Store submissions are separate.