Mobile Release Checklist

Mobile releases are the least forgiving deploys in software: once a build ships, you cannot hotfix users onto the new version — you can only ask them to update and wait out the store review. This skill runs a release train that respects that asymmetry: verify before submission, stage the rollout, watch the crash signal, and keep a kill-path for the features you cannot recall. Every release is treated as reversible-by-flag even though the binary itself never is.

When to use this skill

• Preparing a release candidate for store submission
• Running the staged rollout after approval and deciding when to widen it
• A post-release crash spike demands a halt-or-hotfix decision
• Setting up a repeatable release process for a team currently shipping ad hoc

Instructions

Work the phases in order; each has a gate that must pass before the next begins.

1. Cut and freeze. Branch the release candidate; from here, only fixes reviewed against release risk may land on it. Bump version and build numbers by the project's scheme, and tag the exact commit the candidate builds from — the store binary must be traceable to one revision.
2. Verify the candidate, not the branch: fresh install on real devices, and — the one everyone skips — the upgrade path from the currently shipping version with real user data, across the oldest and newest supported OS versions. Exercise the revenue and login flows, offline behavior, and push notifications. Simulators are for development; releases get hardware.
3. Sweep the ship-blockers: signing configuration valid for distribution; debug menus, test endpoints, and verbose logging stripped from the release build; privacy and data-collection disclosures matching what the binary actually does; third-party licenses current; store listing text and screenshots updated if the surface changed.
4. Submit with rollback thinking already done: release notes written for users (what changed for them, not commit summaries), phased rollout selected where the store supports it, and every risky new feature wired to a remote kill switch that was tested before submission — after approval is too late to add one.
5. Roll out in stages and watch the numbers: start at the smallest cohort the store allows, hold for at least one full day of the app's real usage cycle, and compare crash-free rate, key-flow conversion, and new crash signatures against the prior version's baseline before each widening. Widen on evidence, not on silence.
6. Know the halt drill cold: pause the phased rollout, flip the kill switch on the implicated feature, then decide hotfix-versus-wait with the data in hand. A hotfix enters review like any other build — that latency is exactly why the kill switch exists.
7. Close the train: tag the final build, merge release-branch fixes back to the mainline, record the rollout timeline and any halts, and file the one improvement that would have made this release calmer.

Release gate checklist

• Version and build numbers bumped; candidate tagged and reproducible from one commit
• Fresh install and upgrade-from-production verified on hardware, oldest and newest supported OS
• Debug surfaces stripped; signing valid; disclosures match actual behavior
• Kill switches tested for every feature that cannot wait out a review cycle
• Staged rollout plan written, with named metrics and widen/halt thresholds
• User-facing release notes written and reviewed
• Halt-drill owner named for the rollout window

Guardrails

• No release from an untagged or dirty working tree — traceability is non-negotiable.
• The upgrade path outranks the fresh install in test priority; your users overwhelmingly upgrade.
• Never widen a rollout to appease a schedule; the metrics window is the authority.
• Crash-free rate is compared against this app's own baseline, not an industry number.
• If a store review stalls the train, the answer is never to strip a disclosure to pass — fix the behavior or the disclosure until they match.