Release an iOS app update: phased release on App Store

To release an iOS update, you create a new version in App Store Connect with a higher number. You attach a new build, write the "What's New" text, then send it to App Review. Every new version goes back through Apple's review, even a simple bug fix. Before you submit, you pick how it'll be released after approval: manually, right away, not before a set date, or as a phased release over 7 days.

Phased release only affects automatic updates: 1% of those users on day one, all of them on day seven. You can pause it for up to 30 days total, or finish it all at once. This guide follows Apple's help pages, reviewed on November 3, 2026.

I ship updates to my iOS apps with Expo and EAS, including Solys, TradaZen and Nolera. The examples below come from those releases.

Releasing an iOS update: the steps in order

The App Store Connect help page on new versions lays out this flow:

1. In Apps, pick your app, then click the + button next to the platform.
2. Enter a version number higher than the previous one, then click Create.
3. Review the metadata: it's copied over automatically from the live version.
4. Upload a new build with an incremented build number.
5. Test that build in TestFlight, add it to the version, then submit it to App Review.

Two requirements before you start. The live version must have the Ready for Distribution status. And you need one of these roles: Account Holder, Admin, App Manager or Marketing.

There's no rollback. Apple says so on the same page: if a version has a problem, you can't go back to the previous one. You have to create and submit a new version.

Version number and build number

The version is the number your customers see on your product page. The build identifies each upload. The version and build pair must be unique: the rules and related errors are in version and build number.

My convention, which isn't an Apple rule: the last digit goes up for a fix, from 1.4.0 to 1.4.1. The middle one goes up for a new feature, from 1.4.1 to 1.5.0. The build number only ever goes up, from one version to the next. With Expo, the version lives in app.json and EAS can increment the build on every production build. The setup is in publish an Expo app with EAS.

The "What's New" text: what Apple requires

The version information page describes the What's New in This Version field:

• 4,000 characters max.
• Not shown for the first version, required for every one after.
• Localizable in every language of your product page.

Guideline 2.3.12 of the App Review Guidelines adds a requirement: clearly describe new features and product changes. A generic line is fine for simple bug, security or performance fixes. A significant change must be listed. So "Bug fixes and improvements" isn't enough for a version that changes your subscription or your main screen.

On its ratings and reviews page, Apple also recommends mentioning in your notes the fixed issues that customers described in their reviews.

Here are three templates to adapt, one per type of version.

For a bug fix:

Fixes and stability.
- [Feature]: [what wasn't working] is fixed.
- [Screen] loads faster.
Thanks to everyone who reported it.

For a new feature:

New: [the feature, in five words].
[What you can do now, in one sentence.]
Where to find it: [tab] > [button].

Also in this version:
- [Visible improvement].
- Bug fixes.

For a changed flow:

[Screen or flow] is changing.
- What changes for you: [concrete effect].
- What you keep: [data, settings, purchase].
Questions? [Settings] > [Help].

The last line of the bug fix template only applies if someone actually reported the issue. Never list a new feature that isn't in the build: guideline 2.3 requires metadata that accurately reflects the app.

Manual, automatic or scheduled release

The help page on release options offers three:

Option	After Apple's approval
Manual	Pending Developer Release status, you release whenever you want
Automatic	The version goes live as soon as it's approved
Automatic, no earlier than...	It waits for the chosen date, then goes live on its own

With a manual release, you open the version in Pending Developer Release status, click Release This Version, then confirm. Apple warns it can take up to 24 hours to appear on the App Store. A message on the version page offers Cancel This Release to back out. If the version stays pending for more than 30 days, Apple sends you a reminder email.

Manual release lets you choose the moment, for example to launch on the day of an announcement. Solys 2.0.0, which shipped a new version of the annual subscription, went to review in late September 2026 with manual release.

For a routine version, I leave it on automatic. Nolera 1.0.2, approved on October 12, 2026, showed up on the App Store less than a minute after Apple's email, according to the public iTunes Search API. That's a single observation: plan with some margin.

Phased release over 7 days

Apple's help page on phased release gives the exact schedule:

Day	Share of users
1	1%
2	2%
3	5%
4	10%
5	20%
6	50%
7	100%

The update goes to a random sample of users who have automatic updates turned on, on compatible devices. They aren't told they're part of it.

Phased release only slows down automatic updates. Apple points out that anyone can download the new version from the App Store at any time. Someone who installs your app, or taps "Update" on your product page, can get it on day one. It's not a test on 1% of your users: it's a brake on everyone else.

To turn it on, open the version, scroll to the Phased Release for Automatic Updates section, check "Release update over a 7-day period using phased release", then save. You need the Account Holder, Admin or App Manager role. The option stays available up to the Pending Developer Release status: you can still turn it on after Apple's approval, as long as the version is waiting for your manual release.

Once the version is approved, its Ready for Distribution status shows the "Phased Release" label. At the end of the 7 days, the app's Admins and App Managers get a notification.

Pause, resume and release to everyone

• Pause: up to 30 days total, split as many times as you want. A 10-day pause leaves 20 days for the next ones.
• Resume: the rollout picks up on the day where you stopped it.
• Release to everyone: the Release to All Users button, at the top right of the version, sends the update to all devices with automatic updates.
• Removing from sale: it stops the rollout for good, including if your developer program membership expires. If the app goes back on sale, the version is available to everyone at once.

After releasing to everyone, nothing else can be adjusted, according to the editable properties table.

Nolera 1.0.2 shipped without phased release. Here's how I'd use it during the week:

What you see	What you do	What happens
Crashes or worried reviews	Pause	Automatic updates stop
The fix is ready	New version	It goes back to review, with its own phased release
Nothing unusual after 3 or 4 days	Release to All Users	Everyone gets it
You're waiting to hear from Apple	Pause, 30 days total	Resumes on the day where you stopped

During a pause, manual downloads keep going. Check phased release for any version that touches payments or the first launch: that's where a bug costs the most, and you won't be able to roll back.

When the fix is urgent: expedited review

Apple lets you request an expedited review. It's reserved for real emergencies: a critical bug to fix, or a release tied to an event.

1. Submit your version first. Describe the bug in the Notes field for the reviewer.
2. Fill out the expedited review request form, then pick your app and its platform.
3. Apple speeds up the review depending on availability. Nothing is guaranteed.

For an event, put its date and your connection to it in the notes. The usual timelines are in App Store review time.

What goes back through review, and what doesn't

Change	What it takes
Native code, permissions, SDK version	New build, new version, full review
Screenshots, description, keywords, What's New	A new version, reviewed along with it
Promotional text	Nothing: it changes without a new submission
Pause, resume, release to everyone	Nothing: these are release settings
iOS 27 product page header	On its own in Asset Library, or with a version
JavaScript fix, with Expo	An over-the-air update is possible

Promotional text changes without a new submission, according to the version information page. With Expo, an over-the-air update changes JavaScript, text and images without going through the App Store. Expo's documentation sets two limits: native code, permissions and the SDK version require a new binary, and updates must follow App Store rules.

My case: an over-the-air fix the reviewer never saw

In September 2026, a Nolera build was waiting for review. I'd fixed a bug on the scan screen and published that fix as an over-the-air update while waiting. The build still got rejected, for that already-fixed bug.

The explanation is in the expo-updates documentation: by default, the app downloads the update at launch and applies it on the next launch. The reviewer installs the app, launches it once, and tests the code bundled in the build. The same rule applies to your new users: their first session runs on the build's code.

Since then, any change to the home screen, the paywall or the main feature goes into a new build. Over-the-air updates are only for people who already have the app.

Resetting your rating with a version

Every new version offers the Reset rating when this version is released option. According to Apple's help page on resetting ratings, it applies to all countries, keeps written reviews and can't be undone after release. Apple advises using it sparingly, since a product page with few ratings can put people off.

The checklist before submitting your update

• The version number is higher, the build is incremented.
• The build is tested in TestFlight, on a small iPhone and on iPad if your app runs there.
• What's New is written in every language, and significant changes are listed.
• Screenshots show the current interface if it changed.
• The reviewer notes say what changed and where to find it.
• The release option is chosen: manual if you have to hit a date.
• Phased release is checked if the version touches payments or the first launch.
• You know whether a potential fix can go out over the air, or whether it'll need a build.

Passing review with every update

Every update goes back in front of App Review, and a rejection blocks your fix. The Review Kit bundles my pre-submission checklist, my fixed rejections and two Claude Code skills that review your project and your product page, then draft your reply if Apple rejects you. The full path is on the publish an app on the App Store page.

If you're preparing your first release, take your free diagnostic: it puts the steps in order and sends you my Apple anti-rejection checklist.

Frequently asked questions

How long does a phased release take on the App Store?

Seven days: 1% of users with automatic updates on day one, then 2, 5, 10, 20 and 50%, and 100% on day seven. You can pause it for up to 30 days total, or finish it anytime with Release to All Users.

Does an iOS app update go through Apple's review again?

Yes. Every new version, with its build and metadata, goes through App Review. Promotional text and release settings, on the other hand, change without a new submission.

Can you roll back to an older version of an app on the App Store?

No. You have to create a new version with the fix and submit it for review. That's why phased release and its pause are useful.

Do new users get the update during a phased release?

Yes, if they download the app from the App Store. Phased release only controls automatic updates: anyone can download the new version at any time.

Can you turn on phased release after Apple's approval?

Yes, as long as the version is in Pending Developer Release status, meaning set to manual release and not yet published. Once the version is out, it's too late for that version.

What should you put in an update's release notes?

New features and significant changes, clearly listed: that's guideline 2.3.12. For a simple bug, security or performance fix, a generic line is enough. The field takes 4,000 characters and can be localized in every language.