How to update your app on the App Store: 6 steps (2026)

By Sigsten Gustavii· 14 October 2026· Updated 27 October 2026· 9 min read

Putting an app on the App Store is a milestone; keeping it there means updating it. Every fix, new feature or change to the listing that Apple has to review goes out as a new version, and each one passes through App Review like the app's original submission.

The process is the same whether you change one word or rebuild half the app. Here it is in six steps, with what Apple asks for at each one, then how Borel turns it into one button.

Before you start: version number and build number

Every update carries two numbers, and mixing them up causes most of the errors people meet.

Apple matches each uploaded build to its version record by the bundle ID and the version number, and uses the build string to identify that exact build everywhere in its systems. So when you try three builds of version 1.2.0 in TestFlight, the version stays 1.2.0 and the build goes 47, 48, 49.

Apple asks for an incremental version number: each new one higher than the last. A common convention is to change the last number for small fixes (1.2.0 to 1.2.1), the middle one for new features (1.2 to 1.3), and the leading one for a big redesign (1.x to 2.0).

Step 1: Make the change and test it

Build the new version and try it on a real iPhone, on the iOS versions people use. TestFlight is the usual way to do that: upload a build, install it from the TestFlight app, and send it to a few testers before it goes to everyone. Pay extra attention to anything that touches saved data. An update must open cleanly on a phone that already has the old version and its data, not only on a fresh install.

Step 2: Raise the version and build numbers

Set the new version number, then increase the build number before you upload. Apple's own instruction is to increment the build string in Xcode before each upload. An upload that reuses a build number Apple has already seen is refused.

Step 3: Create the new version in App Store Connect

1. Check that the current version's status is Ready for Distribution, which Apple requires before a new version can be made.
2. In Apps, open your app.
3. In the sidebar, click the + next to the platform, such as iOS.
4. Enter the new version number, matching the one in your build, and click Create.
5. Review the metadata. Apple copies the description, keywords, screenshots and other details from the current version, so you only change what is new.
6. Click Save.

Updating screenshots is worth a minute here when the change is visible. A new feature that no screenshot shows is a feature most people browsing will never notice.

Step 4: Write the What's New text

What's New is the short note people see on your product page and in the App Store's update list. Apple requires it for every version after the original one, allows up to 4,000 characters, and lets you localise it.

Guideline 2.3.12 sets the rule: new features and product changes must be described clearly. Small bug fixes, security updates and performance work may use a generic line, but significant changes have to be listed.

If you only want to change the marketing line above your description, use promotional text instead. It holds up to 170 characters and can change without submitting a new version.

Step 5: Attach the build and choose the release

Upload the build. Apple processes it and emails you when it is ready. Then, on the version page, add that build to the version and choose how the version goes live once approved:

• Manual: approval moves the version to Pending Developer Release, and you release it when you choose.
• Automatic: it goes live as soon as App Review approves it.
• Automatic, no earlier than a date: approved early, released on the date you set.

For an app many people rely on, also consider phased release for automatic updates. Over 7 days, Apple delivers the update to a growing random share of people who have automatic updates on: 1%, 2%, 5%, 10%, 20%, 50%, then everyone. Anyone can still download it by hand from the App Store at any time. You can pause the rollout for up to 30 days in total if something looks wrong, or release it to everyone at once from the version page when you are confident. You can switch it on while the version is being prepared, waiting for review, in review or pending your release.

Step 6: Submit the update for review

Submit the version to App Review. Apple reviews every update, and says it typically reviews at least 50% of submissions in under 24 hours and 90% in under 48. Our post on how long App Store review takes explains each status along the way. While the update is in review, the current version stays on the App Store as it was.

Two exceptions help when you are in a hurry. For a critical bug fix, you can request an expedited review, with steps to reproduce the bug in the live version. And if Apple finds other issues while reviewing a bug-fix update, it may offer to approve the fix now and let you resolve the rest in your next submission, as long as there are no legal or safety concerns.

If the update is rejected, Apple names the guideline in its message. Fix it, upload a new build if the code changed, and resubmit; what to do when your app is rejected covers replies and appeals.

Updating your app with Borel

If your app was made and published with Borel, an update is the same chat you built it in, plus one button. Publishing is part of Borel Pro, from $20 a month.

1. Ask for the change in the chat, and try it in the iPhone simulator in your browser or on your own iPhone.
2. Press Publish an update. It appears on a released app in My apps and in the publish flow. Borel makes the next version, builds your latest changes on its Mac and sends them to Apple. The live app stays up until the update is approved.
3. Numbers handled. Borel suggests the next version number by raising the last one, for example 1.0.0 to 1.0.1, and gives every build a new build number of its own, so no upload ever reuses one.
4. What's New written for you. Borel writes it from the changes you asked for since the last release, in plain sentences about what people will notice. It never mentions AI, Borel or how the app was made, as Apple wants the note to be about the app.
5. The listing carries over, and the build is attached to the new version for you, not to the live one.
6. Submit for review from the same window, then follow the status, read live from Apple. Borel can email you when Apple approves or rejects the version, and a rejection opens a panel that lets you fix the problem and send the same version back.

Phased release and the manual or automatic release choice stay in App Store Connect, on the version page, if you want them. The Publishing page in Borel's docs shows each screen.

Before I publish an update: list the changes I asked for since the last release, check the app still opens with the data people saved in the old version, and fix anything that would break for them.

Common update mistakes

The bottom line

Updating an app on the App Store takes six steps: make and test the change, raise the version and build numbers, create the new version in App Store Connect, write a clear What's New, attach the build and choose the release, then submit for review. The old version stays live until the new one is approved, and phased release lets you roll out carefully. If your app lives in Borel, Publish an update does the numbers, the notes and the upload for you.

I think the update you ship is worth more than the perfect one you keep polishing. Small, regular versions with honest notes are how an app gets better in public.

– Sigsten

Make your iPhone app in Borel

Describe the app you want and see its first screens before you pay anything.