How do you pause a bad mobile release in the first hour?

Pause the Apple phased release, halt the Google Play staged rollout, then ship a fixed build. Pausing stops new users receiving the bad version. It does not remove it from people who already have it, so the fix still has to go out as a new release.

Before you need it

Small studios lose the first hour hunting for who has access. Settle these now.

• Apple role. Pausing a phased release needs the Account Holder, Admin or App Manager role in App Store Connect.
• Play access. Someone with release rights on the Releases tab must be reachable.
• Phased release on. The pause control only exists if you chose phased release when you submitted the update.
• Trigger. Write down what counts as bad: crash spike, login failure, payment error.

The runbook

1. Confirm it is the release. Compare the new build with the previous build, not with last week. A bad SDK often shows as crashes at launch or one broken feature.
2. Pause on Apple. In App Store Connect, open the Ready for Distribution version, choose Pause Phased Release in the phased section, then Save. The total pause budget is 30 days, and rollout resumes from the day you paused.
3. Halt on Google Play. In the Releases tab choose Manage rollout, then Halt rollout. No additional users receive that version.
4. Say what it does not do. Installed copies stay. Apple also notes that anyone can still download a phased release manually, so a pause is not a block.
5. Decide fix or revert. Reverting the SDK in code and shipping a new build is usually the quickest path. Google recommends a new release with a fixed bundle rather than resuming a halted one with a problem.
6. Ask for speed if it is a critical bug. Apple allows expedited review requests for a critical bug fix, with steps to reproduce on the current version. See the separate post on expedited review.
7. Tell users plainly. If the break affects accounts or payments, a short status note beats silence.

What a pause cannot fix

A pause cuts the spread, not the damage. If the bad version sends data it should not, or breaks a login flow, the users in the early group are still affected. This is why the first rollout step should be small. Apple's schedule starts at 1% on day one.

If the problem is a security flaw in the SDK, not a crash, treat it as an incident: check what the SDK sent, rotate any keys it touched, and note the dates in your records.

After the hour

Write down the time from first signal to pause. That number tells you whether your watch routine works. Add the lesson to your SDK upgrade checklist and keep the failing build artefacts for the post incident review.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how findings are grouped by affected component, which is how you find every app that ships the same SDK.

Safeguard provides SBOM and dependency scanning, so you can list which of your apps include the faulty SDK version. You can try a free scan.

Quick check

Sources

• Apple: Release a version update in phases
• Google Play Console Help: staged rollouts
• Apple: App Review

Last reviewed: 19 October 2026.