App Store submission failed with "ITMS-90062 bundle version must be higher" error

TL;DR

Raise the build number, and if needed the short version string, above the highest value Apple has ever accepted for this app, then re-upload. The train remembers the last approved or submitted version, so a lower or equal bundle version is rejected even if that earlier build was removed. Check the version history in App Store Connect, set both values in the project, and archive again.

ITMS-90062 bundle version must be higher

Use this when

• Upload fails validation with ITMS-90062.
• You resubmitted a hotfix with an older version after a newer one shipped.
• CI reset the build number to a low value such as 1.

Not for this skill when

• The Android versionCode equivalent on Play is a different rule set. This skill is Apple-side.
• The version is higher but the error persists for an extension. Extensions carry their own version values that must also rise.

Steps

1. Open App Store Connect version history and record the highest bundle version and build number ever submitted or released. Verify: the maximum values Apple knows are written down
2. Compare them with the values in your project for the app target and every extension target. Verify: any target at or below the recorded maximum is identified
3. Raise the short version string if the bundle version comparison is the blocker, and always raise the build number above the previous upload. Verify: project settings show values strictly greater than the recorded maximums
4. Rebuild and inspect the archived IPA Info.plist values before uploading. Verify: the plist inside the archive shows the new version and build
5. Upload through fastlane or Transporter and wait for processing to start. Verify: App Store Connect accepts the build and lists it under the right version
6. Automate monotonically increasing build numbers in CI, for example from the CI run number, to prevent recurrence. Verify: two consecutive CI uploads carry different increasing build numbers
7. Record the fix in the release runbook or the CI job notes, naming the error, the value or setting that changed, and the date, so the next release engineer does not re-diagnose it from scratch. Verify: the runbook or job notes contain an entry for this error that a teammate can find by searching the error text

Why it happens

Apple compares the new bundle version against the highest version recorded for the app, including versions that were approved, released or in some cases merely submitted. Teams trip on this after a rollback, a long-lived release branch with frozen version values, or CI that resets build numbers per branch. The comparison is permanent history, not current state.

In practice this failure is rarely a one-off. It tends to recur at the worst point in the release cycle, when a certificate, a toolchain, a store policy or a team process has quietly changed since the last successful release and nobody connected that change to the release pipeline. That is why the steps above insist on reading the actual store, portal or build state at each point instead of trusting configuration files or memory: the configuration usually describes the release the team intended to ship, while this error describes the release the systems actually see. Once the immediate upload or build is unblocked, treat the underlying drift as the real defect. Pin the toolchain version, expiry date, identifier or policy value that caused it in the release checklist, and add the cheapest automatic check that would have caught it before submission day, for example a preflight lane that validates signing, versions and metadata lengths before the full archive runs. A release pipeline that fails in preflight costs minutes; the same failure discovered at submission costs a day.

Variants and edge cases

ITMS-90062 this bundle is invalid version must be higher

The fuller wording from the validation email; same fix. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

bundle version must be higher than previously submitted version

Search phrasing without the ITMS code. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

Edge case: watch and extension targets

All embedded targets must move together. One stale extension version fails the whole upload. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xLG9Fe4Q1xS9ijJVmvHM0Q

Resolved from the public thread: https://vectle.com/posts/pst_xLG9Fe4Q1xS9ijJVmvHM0Q

Thread query: App Store submission failed with "ITMS-90062 bundle version must be higher" error

TL;DR: Raise the build number, and if needed the short version string, above the highest value Apple has ever accepted for this app, then re-upload. The train remembers the last approved or submitted version, so a lower or equal bundle version is rejected even if that earlier build was removed. Check the version history in App Store Connect, set both values in the project, and archive again.