TL;DR. Phased release, the toggle in App Store Connect that rolls an update out to automatic-update users over 7 days at 1/2/5/10/20/50/100%, only governs existing users with automatic updates on. It does nothing to slow down new installs, manual updates, or how fast your new metadata reaches App Store search. Your updated keyword field, subtitle, and screenshots go live for 100% of new visitors and new installs the instant the version clears App Review, regardless of what percentage phased release shows. Treat it as a crash/regression safety net for your binary, not a safety net for a risky ASO change.
Phased release looks, from the App Store Connect UI, like a dial you can turn slowly. That reads as caution, and a lot of indie developers extend that read to metadata: “I’ll ship the new subtitle with phased release on, so if it tanks conversion I can pause before everyone sees it.” That reasoning is wrong, and it’s wrong in a way that matters if you’re timing a metadata change around it.
Does phased release delay my new keywords, subtitle, or screenshots from going live?
No. Phased release only throttles the automatic app update pushed to existing users’ devices. Your product page — title, subtitle, keyword field re-indexing, screenshots, description, promotional text — updates for every new visitor and every new install the moment Apple approves the version, at whatever percentage phased release happens to be sitting at, including 1%.
Apple states this directly in the App Store Connect Help documentation: manual downloads and new installs are not subject to phased release at any point during the rollout. So is a competitor teardown, a screenshot in a review, or a Safari search result showing your new product page the day after approval — none of that is gated by the phased-release percentage. The dial you’re watching tick from 1% to 100% describes how fast existing users get the new binary. It says nothing about how fast the store listing itself changes for everyone else.
If you’re testing a metadata change and want a controlled rollout, the correct tool is Product Page Optimization, which runs actual treatment variants against live traffic and lets you compare conversion before committing. Phased release was never built for that job.
What percentage of users actually get the update each day?
Apple’s fixed schedule is 1% on day 1, 2% on day 2, 5% on day 3, 10% on day 4, 20% on day 5, 50% on day 6, and 100% on day 7. It’s not configurable — you can’t set your own ramp, only pause the one Apple gives you.
| Day | Cumulative % on new version (automatic updates only) |
|---|---|
| 1 | 1% |
| 2 | 2% |
| 3 | 5% |
| 4 | 10% |
| 5 | 20% |
| 6 | 50% |
| 7 | 100% |
Turning phased release on is a per-version choice you make at submission, under the version’s build settings in App Store Connect. It requires the Account Holder, Admin, or App Manager role. If you skip it, the update ships to 100% of automatic-update users immediately on approval, same as it always did before phased release existed.
Can I pause a phased release, and what does pausing actually stop?
Yes — you can pause at any point during the 7 days, for a cumulative total of up to 30 days across however many pauses you use, with no cap on the number of times you pause. Pausing freezes the percentage at whatever day you’re on; it does not roll anyone back to the previous version.
Two behaviors catch people off guard:
- Pausing doesn’t stop users still catching up to the current tier. If you’re at day 3 (5%) and pause, the rollout stops advancing toward day 4, but Apple keeps delivering the update to eligible users until that 5% figure is fully reached — pausing halts the ramp, not the delivery already in motion.
- You have to pause before the next 24-hour tick, not after. Once the day rolls over, the jump to the next percentage (say, 5% to 10%) has already happened, and there’s no partial-rollback option.
You can also skip straight to 100% at any point with the “Release to All Users” control on the version page, and if you pull the app from sale mid-rollout, phased release stops permanently for that version — it can’t be resumed later, even if you restore the listing.
The actual failure mode this causes
A developer ships a version with a broken deep link buried in a subtitle rewrite, turns phased release on, and watches conversion in App Store Connect Analytics. Nothing looks wrong for a day, because the only traffic affected by the phased-release percentage is existing users getting the binary update — and most of them weren’t going to re-read the new subtitle anyway, since they already have the app. Meanwhile every new visitor from search, the App Store’s “You Might Also Like,” or a link from a review site is hitting the new subtitle at full volume from day one. By the time the phased-release dial reaches 50%, the metadata damage — or the metadata win — has already fully played out on the audience it actually affects: people deciding whether to install.
If you’re validating a subtitle, keyword, or screenshot change, watch new-user conversion metrics from day one, not the phased-release percentage. If you’re worried about a binary regression — a crash, a broken feature, a performance cliff — phased release is exactly the right tool, because that’s the audience it actually gates: people who already have your app and are about to get new code on their device.
What to do before your next submission
- Decide what you’re actually trying to protect: existing-user stability (use phased release) or new-install conversion (use Product Page Optimization, not phased release).
- If you’re shipping a metadata change alongside a build, don’t wait for the phased-release percentage to climb before checking conversion — new installs see the change at 100% immediately.
- If a crash or regression shows up mid-rollout, pause before the next 24-hour tick, then decide between a hotfix build or “Release to All Users” once you’ve confirmed the fix.
- Confirm you have Account Holder, Admin, or App Manager access before submission day — phased release isn’t available to every App Store Connect role.