App Store Phased Release, Day by Day

An expense splitter is about to ship a sync fix. This is not financial advice and not a bank. It is a version update that divides a dinner, and you do not want every automatic update to take the build in the first hour if the sync eats a receipt. Phased release is Apple’s fixed seven-day ladder for that situation. You do not pick the percent. You watch the early days, and you pause if the crash log earns it.

The ladder and the pause rule are on Release a version update in phases . Play’s version, where you choose the percent and it does not climb by itself, is Google Play staged rollouts. What you tell people in the version note is What’s New. If the sync bug already has reviews, answer them in how to reply to App Store reviews.

The seven days, exactly

When you submit a version update you can choose to release it gradually over seven days. A random sample of users who have automatic updates on, on eligible devices, get the update. They are not told they are in a phased release. The percentages are fixed.

Day 1 is 1%, day 2 is 2%, day 3 is 5%, day 4 is 10%, day 5 is 20%, day 6 is 50%, and day 7 is 100%. The steps are Apple’s. They do not speed up because the first night looked fine.

Pause uses a 30-day budget

You may pause for up to 30 days, and there is no limit on the number of pauses inside that total. Apple’s own example: pause for 10 days, resume, and you have 20 days of pause left. When you resume, the release picks up on the day it was on when you paused. A pause on day 3 does not restart you at day 1, and it does not skip you to day 7. Required role to manage this is Account Holder, Admin, or App Manager.

On the version page, the Phased Release for Automatic Updates section is where you pause or resume. You can also release to all users once the version is Ready for Distribution, which gives the latest supported version to devices with automatic updates on. That is the “stop waiting” button. Use it when the sync fix is boringly fine. Do not use the first quiet hour as proof. One percent is a small room.

The first release cannot use it

The control shows up when you submit a version update, for an app already in a status that allows the submission. A brand-new expense splitter’s first release goes out the ordinary way. If you wanted a staged first public build, that was TestFlight, internal then external, before you ever hit Ready for Sale. Phased release is how you limit automatic updates of a version you are shipping on top of an app people already have.

Removing the app from sale stops the phased release, and that version cannot use phased release again. If membership lapses, that counts as removal. When the app comes back, it is available to everyone immediately, regardless of the percent you had reached. To get a controlled rollout after that, make the version unavailable for download and submit a new version update with phased release on. Do not yank the app to “pause.” Pausing is the 30-day control. Removal is a different door.

Watch crashes while the percent is still small

Day 1 is the point of the feature. If the sync fix crashes when two people edit the same dinner, you want that on 1% of automatic updates, not on all of them. Pause, ship a follow-up, and reply to anyone who already wrote. There is no official crash-rate threshold in the phased-release article, so do not invent “pause above 0.5%.” Pause when you would be unwilling to explain the crash in a public reply. Day 6 at 50% is a late time to discover a startup loop.

Users are not notified that they are in the phased release. They will still blame the app, and they can still review. A reply that says “you’re in a random 2% bucket” is not helpful. A reply that says which version fixes the sync, and what to do if they tapped Update manually, is helpful. Manual updaters may be on the build before your automatic-update chart says the day has reached them.

Treat the listing as live

The phased-release article describes how the update reaches automatic updates. It does not say the product page keeps the previous screenshots, description, or What’s New until day 7. Do not plan on the new metadata staying hidden. Treat the listing copy as live when the version is released. If What’s New mentions the sync fix, assume shoppers can read that on day 1, including people whose phones have not auto-updated yet, and including people who download the build by hand.

On iOS, metadata other than promotional text ships with the version. Promotional text is 170 characters, can change without a binary, and does not affect ranking. It is the wrong place to pretend the listing is still on the old build. Write What’s New as public copy. The Play contrast is real and different: you choose Play’s percent, it does not advance on a calendar, and Google recommends listing changes after 100% when the listing must match the new bundle. Apple’s ladder is the calendar. Your words should be ready on day 1.

What phased release will not do

It will not hide the build from someone who updates manually. It will not restart the percent because you paused. It will not apply to the first release. It will not give you a custom 15% on day 2. It will not survive a removal from sale on that same version. And it is not a substitute for reading crashes. The expense splitter’s sync bug is a product failure whether 1% or 100% can hit it. The ladder only buys you time to notice.