How to Submit an App Update to the App Store (Step by Step)

Submitting an app update to the App Store is the same loop every time: raise your version number, raise your build number, produce a new binary, upload it to App Store Connect, create a new App Store version that points at that build, write the release notes, and submit for review. A binary change (any change to native code, permissions, SDK versions, or anything that is not pure JavaScript and assets) has to go through this loop. There is no shortcut around review for a native change, and trying to find one is how apps get flagged.

The reason updates feel harder than the first launch is that the first launch is a checklist you follow once, while updates are a routine you repeat for the life of the app. The people who ship a steady stream of updates are not doing anything clever; they have turned the loop below into muscle memory so a release takes twenty minutes of attention instead of an anxious afternoon. This is the loop, in order.

Every App Store update involves two numbers that do completely different jobs, and mixing them up is the single most common reason an upload gets rejected before it even reaches review. The version number is the public, human-facing number like 1.2.0 that users see on your App Store page. The build number is an internal counter that identifies one specific binary. App Store Connect enforces one hard rule: the build number of a new upload must be strictly higher than any build number you have ever uploaded, even for a different version.

In practice this means the version number increases when you want users to see a new release, and the build number increases every single time you upload a binary, including the third re-upload of the same version after you fixed a rejection. If you upload version 1.2.0 build 5, get rejected, and re-upload as version 1.2.0 build 5 again, the upload fails. It has to be build 6. Treat the build number as an ever-increasing odometer that never resets and never repeats.

Open your Expo app config and raise the version to the new public number, following major.minor.patch: a patch bump (1.2.0 to 1.2.1) for bug fixes, a minor bump (1.2.0 to 1.3.0) for new features, a major bump for a significant redesign. Then either raise ios.buildNumber by hand or, better, enable auto-increment so the build tooling handles it. With that set, produce the release binary with a single command: eas build --platform ios --profile production.

This is a place the Claude Code desktop app earns its keep. Point it at your project and describe the release (a patch fix, a new feature) and it can make the correct version bump in your config, confirm the build number is set to auto-increment, and kick off the build for you, so you are not hand-editing a config file and second-guessing which number to touch. The terminal is there if you prefer it, but you do not need to memorize the commands to run this loop cleanly.

Once the build finishes, upload it to App Store Connect. With EAS this is one command: eas submit --platform ios --profile production, which takes the build you just produced and delivers it to Apple. After the upload, the build does not appear instantly; App Store Connect runs it through automated processing that usually takes a few minutes to half an hour, and only then does the build show up as available to attach to a version.

Do not start the next step until the build has finished processing and appears in the Build section of your app in App Store Connect. If you added any new permission or a data-collection SDK, this is also when you confirm your App Privacy answers still match what the app actually does, because an update that quietly starts collecting new data with stale privacy answers is a rejection waiting to happen. The details of getting those answers right are in the guide on [app privacy details in App Store Connect](/blog/app-privacy-details-app-store-connect).

In App Store Connect, on your app's page, add a new version using the same version number you set in your config. This opens a fresh version page where you attach the build you just uploaded and fill in the What's New in This Version field, which is the release notes users read before they update. Release notes are required for every update, and a blank or lazy note (like the tired 'bug fixes and performance improvements') is a missed conversion: the note is a small piece of App Store copy that tells returning users why to tap Update.

Phased release is a setting on the version page that rolls your update out to a growing percentage of your existing users over seven days instead of all at once: roughly 1 percent on day one, climbing to 100 percent by day seven. This is the single most useful safety net for an independent builder, because it means a bad build that slipped past your own testing reaches a small fraction of users first, giving you time to catch it in your crash reporter and pause the rollout before it hits everyone.

Turn it on for every update that has any real code change. You can pause a phased release at any point from App Store Connect if something looks wrong, fix it, and resume, and you can release to all users immediately if the update is clean and you want it out fast. New users who install for the first time always get the latest version regardless; phased release only governs how fast the update reaches people who already have the app. Pair it with the crash reporting from the guide on [adding crash reporting to your Expo app](/blog/how-to-add-crash-reporting-to-your-expo-app) so you actually see the problem during that first slow day.

With the build attached, release notes written, and phased release set, click Add for Review and then Submit. The update enters the same review queue as a first submission. Apple publishes that on average the majority of submissions are reviewed within about 24 hours, but that is a throughput average across all apps, not a promise about yours, so never build a hard launch date on a specific review time. An update is approved, rejected with a specific guideline reason, or occasionally held in review longer for a manual look.

If the update is rejected, treat it exactly like a first-launch rejection: read the guideline Apple cites, fix that one specific thing, raise the build number, and resubmit. An update rejection is usually narrower than a first rejection because most of the app already passed, so it is often a single metadata or behavior issue. If it is approved and you chose phased release, the rollout begins automatically; if you chose to release manually, it sits in a Pending Developer Release state until you press the button.

Not every change needs this loop. If your update is pure JavaScript and assets (a copy fix, a color change, a logic tweak, a bug fix in your React code) you can ship it over the air with an update service and skip App Store review entirely, so users get it within hours. The full submission loop is only mandatory for a binary change: new native modules, new permissions, an SDK or Expo version bump, or anything that alters what is compiled into the app.

The discipline is knowing which bucket a change falls into before you start. A native change goes through the five steps above; a JavaScript-only change goes over the air. Confusing the two either wastes a full review cycle on a change that did not need one, or tries to push a native change over the air where it simply will not take effect. The full mechanics of the over-the-air path are in the guide on [pushing app updates without App Store review](/blog/how-to-push-app-updates-without-app-store-review).

Put together, the whole thing is a short, repeatable routine you run every time you ship. Once it is muscle memory, a routine update is a twenty-minute job, and the phased release plus a crash reporter mean a mistake is contained instead of catastrophic.

Members inside App Store Launch Club run this loop together, post their release notes for a second pair of eyes, and compare crash-reporter dashboards during that first phased-release day so a bad build gets caught early. If you want the update routine and the rejection fixes in one place instead of learning them one painful release at a time, join at applaunchclub.co for $9 a month.