App Store phased release: how the 7-day rollout works, when to pause and how to ship a fix (2026)

An App Store phased release sends a version update to a growing share of users with automatic updates on over seven days, starting at 1% on day one and reaching 100% on day seven. If you check crashes and support email every day and pause as soon as something looks wrong, a bad build reaches a small group of people instead of your whole user base. Phased release has one big limit, though: it only controls automatic updates. Anyone can still download the new version manually.

What does App Store phased release control, and what doesn't it?

Phased release controls only which users with automatic updates on get your version update, and when. It doesn't hide the new version from manual downloads, and it doesn't roll back anyone who already has it.

According to Apple's App Store Connect Help, "A random sample of users with automatic updates on eligible devices will receive the update, without any notification of their participation in the phased release." It works for iOS, macOS and tvOS version updates, so you can't use it for an app's first release. Setting it up needs the Account Holder, Admin or App Manager role. Apple also states: "Apps and app updates in phased release can be manually downloaded from the App Store by anyone at any time."

What is the App Store phased release schedule?

As of November 2026, the schedule is fixed at 1%, 2%, 5%, 10%, 20%, 50% and 100% over seven days, and you can't edit it. What you control is when to pause and when to skip straight to 100%.

Treat each day as a checkpoint that ends with one decision: carry on or pause.

How do you turn on phased release in App Store Connect?

Phased release is switched on from the version page, under Phased Release for Automatic Updates, any time before the update goes live. You don't have to decide before you submit.

Apple allows it while the version is in Prepare for Submission, Waiting for Review, In Review, Waiting for Export Compliance, Pending Developer Release, Developer Rejected, Rejected or Metadata Rejected.

1. In Apps, select your app, then click the version you are submitting in the sidebar.
2. Scroll to Phased Release for Automatic Updates.
3. Select Release update over a 7-day period using phased release.
4. Click Save. After approval, the status shows Ready for Distribution with Phased Release next to it.

You can also manage phased releases through the App Store Connect API, which helps if your release pipeline is already scripted.

When should you pause a phased release, and how does the 30-day limit work?

Pause as soon as one of your pre-agreed triggers fires. Pauses can add up to 30 days in total, and when you resume, the rollout continues from the day where it stopped.

Write your triggers down before launch day, so nobody is arguing about them while users are hitting the bug. Good triggers are concrete: crash-free sessions fall below the previous version's baseline, checkout or login fails for a measurable share of attempts, or several users report the same bug.

To pause, open the Ready for Distribution version, select Pause Phased Release and click Save. To resume, select Use Phased Release. Apple's example: if you pause for 10 days and then resume, you have 20 days of pausing left. You can pause as many times as you like within that total. To skip the remaining phases, click Release to All Users at the top right of the version page.

What does a phased release look like when a bug shows up?

When a bug shows up, you pause, fix it, and ship a new version with phased release on again. The users who are still waiting for automatic updates stay on the previous version while you work.

Say version 3.4 replaces your sync engine. On day one, 1% of auto-updating users get it, and you check your crash reporter and sync error logs twice. On day three, at 5%, a cluster of sync failures appears on one older iOS version. You pause straight away. Far fewer users are affected than if everyone had received it, and the auto-update users who haven't been reached yet stay on 3.3.

Next, fix the bug and submit 3.4.1 with phased release on. Test the fix in a release build, not only in debug; our release-build test plan covers that step. Say plainly in the 3.4.1 release notes that sync is fixed; our release notes examples show how. If the fix is urgent and you're confident in it, use Release to All Users after approval instead of waiting another week.

One more safeguard: put the new sync engine behind a server-side flag. Pausing stops the update from spreading, but a flag lets you switch the risky code off for people who already installed 3.4. The two work well together.

What have other developers run into when pausing a phased release?

Public threads show the same pattern: developers pause a buggy version, then aren't sure what a follow-up phased release does for users who already got it. Apple's documentation doesn't answer that, so plan as if the fix needs its own rollout.

• A developer on the Apple Developer Forums reported that they "noticed a crash, paused the roll-out of the update, patched the app, uploaded it and started another phased roll-out" with under 10% of users on the bad build. They asked whether the same users would get the new rollout. The thread never got an official answer; one reply said 8.0 users "should get an update that there's an 8.1 update available as soon as it comes out."
• In a separate forum thread, a developer said they "stopped at 1%" on version 15.0.1 because of a critical bug and wanted to stagger 15.0.2 as well, hoping 15.0.1 would be "virtually skipped for the majority of users." An earlier reply in that thread suggested requesting an expedited review while the buggy version was paused, and possibly taking the app off sale "so that no new users grab the fouled version." Before you do that, remember the removal-from-sale rule in the callout above.
• The release-tooling team behind Tramline's store-quirks notes documents that starting a new release "will simply cancel the existing rollout," and the older version moves to REPLACED_WITH_NEW_VERSION with its phased release marked COMPLETE. The same notes say a pause "will not be able to do anything about the users who already received the update."

Across all three, pausing only bought time. The fix was always a new version, and nobody could rely on the same cohort being updated first. That's why server-side flags and a hotfix branch you can ship quickly matter more than the pause button.

How does Google Play's staged rollout compare?

Google Play's staged rollout uses a percentage you choose and raise manually. After a halt, a resume reaches the same set of users. Plan the two stores' rollouts separately.

Per Play Console Help, "your app's staged rollout percentage won't increase automatically," and staged rollouts "can only be used for app updates, not when publishing an app for the first time." After a halt, users who already received the version stay on it, and Google advises releasing a new version with a fixed bundle instead of resuming a broken one. Production rollouts can be limited to specific countries, but once one has started, you can't remove countries. If your next Android update also has to meet the new target SDK, see our guide to target API level 36 on Google Play.

What should you check before starting a phased release?

Before the rollout starts, make sure phased release is saved on the version, your baselines and pause triggers are written down, and a fix can ship quickly. Use this checklist:

• Phased release selected and saved on the version page
• Crash reporting and backend error dashboards bookmarked, with baselines from the previous version
• Written pause triggers agreed by everyone who can press the button
• Risky features behind server-side flags
• A named person checking metrics on each of the 7 days
• A hotfix branch ready, plus our App Store submission checklist for the follow-up build
• Store listing changes held until the rollout reaches everyone

If you'd rather hand off the release itself, our App Store submission service covers App Store Connect and Play Console setup, review preparation and releases on both stores for $599 (developer account fees are separate). For a second opinion on a risky update, email yagyeshsrbobde@gmail.com with your app and what's changing.