Error ITMS-90054 means the bundle identifier in your build does not match the one Apple already has on record for that app, and Apple does not allow an existing app's bundle identifier to change once a build has been uploaded. The fix is almost always to revert your CFBundleIdentifier to the exact original value and re-upload. It is usually caused by a typo, a find-replace, or config drift between Xcode, Fastlane, and Expo. If you truly need a different bundle identifier, you must create a new app record in App Store Connect.
Short answer
ITMS-90054 says "This bundle is invalid. The bundle identifier cannot be changed from the previous version." It means your build's CFBundleIdentifier differs from the one registered for that app, and Apple will not let an established app change it. The fix is to set the bundle identifier back to the exact original value, matching case and with no added suffix, then rebuild and upload. Check Xcode, and also your Fastlane app_identifier and Expo ios.bundleIdentifier, since a mismatch there is a common cause, as seen in reported cases. If you actually want a different identifier, create a new app in App Store Connect.
What ITMS-90054 means
ITMS-90054 is App Store Connect rejecting your upload because the build's bundle identifier does not match the app's existing bundle identifier. The full message is explicit: the bundle identifier cannot be changed from the previous version, and if you want a different one, you must create a new application. It is a hard rule, not a transient error, so retrying the same build will not help.
The bundle identifier is the permanent, unique name of your app, and Apple ties the app record to it. Once you have uploaded any build under a given bundle identifier, that value is locked for the app. ITMS-90054 is simply Apple enforcing that lock when a new upload arrives with a different value.
Why did the bundle identifier change?
In almost every case, the bundle identifier changed by accident, not on purpose. A manual edit to the Info.plist or the Xcode General tab, a project-wide find-replace that caught the identifier, or a refactor that renamed the app can all change it silently. The value usually lives in the PRODUCT_BUNDLE_IDENTIFIER build setting, so anything that touches build settings can move it.
The other common source is config drift between tools. Your Xcode project might be correct while a Fastlane app_identifier or an Expo ios.bundleIdentifier points at a slightly different value, and the tool overrides the project at build time. Because these files are edited separately, they drift apart, and the one that builds the binary wins.
The error-cause matrix
Matching the exact symptom to its cause is the fastest route to a fix. The table below covers the common cases.
| Symptom | Cause | Fix |
|---|---|---|
| Bundle ID differs by a typo | A manual edit or find-replace changed it | Set it back to the exact original |
| Correct in Xcode but error persists | Fastlane or Expo config differs | Align the tool's identifier |
| Error only in CI | CI builds a different scheme or target | Point CI at the right target |
| Uploading to the wrong app | Build's ID matches a different app record | Upload to the matching app record |
| A suffix like .beta was added | Bundle ID intentionally changed | Revert, or create a new app for the variant |
Reading the matrix first saves you from the most frustrating version of this bug, where Xcode looks correct but a tool config is quietly building a different identifier.
Can I revert it? Yes, here is how
Yes, and reverting is almost always the right fix. Find the app's exact bundle identifier in App Store Connect, then set your CFBundleIdentifier back to that value, matching capitalization exactly and removing any accidental suffix. Rebuild and upload, and the error clears because the binary once again matches the record.
The key is to treat the value in App Store Connect as the source of truth, not your local project. If someone changed the identifier deliberately, undo that change rather than trying to make App Store Connect accept the new one, because it will not. Reverting is a normal, safe operation; you are simply restoring the app's real identity.
Checks: Xcode, Fastlane, and Expo EAS
Verify the identifier in every layer that can set it. In Xcode, check the bundle identifier in the target's General tab and the PRODUCT_BUNDLE_IDENTIFIER build setting, for the correct target, since app extensions have their own identifiers. Make sure the scheme you archive is the app, not an extension or a test target.
For automation, align the tool with the project. In Fastlane, confirm the app_identifier in your Appfile or the identifier passed to gym and pilot. In Expo, check ios.bundleIdentifier in app.json or app.config.js, since EAS builds from that value. Whichever tool produces the uploaded binary is the one whose identifier must match App Store Connect, so fix it there, not just in Xcode.
When you actually need a new app record
Sometimes the identifier change is intentional, for a rebrand or a split into a new product. In that case, ITMS-90054 is telling you the truth: you cannot repurpose the existing app record for a different bundle identifier. You must create a new app in App Store Connect with the new bundle identifier and upload there.
Be aware of the trade-off before you do. A new app record is a new App Store listing, with no shared reviews, ratings, or download history, and existing users are not migrated. If keeping continuity matters, revert to the original identifier instead. Only create a new record when a genuinely separate app is what you want.
Certificates, profiles, and the bundle ID relationship
The bundle identifier is also the anchor for your signing assets, which is why a mismatch can cascade. Your App ID, provisioning profiles, and entitlements are all tied to a specific bundle identifier, so changing it can invalidate the profile used to sign the build. A profile that does not match the identifier produces its own signing failures alongside ITMS-90054.
When you revert the identifier, make sure the provisioning profile matches it too. With automatic signing, Xcode usually regenerates the right profile once the identifier is correct. With manual signing or in CI, confirm the profile is for the original bundle identifier, or you will fix the upload error only to hit a signing error next.
Safe retry path
Follow an ordered path rather than re-uploading the same binary. The checklist below moves from confirming the real identifier to a clean re-upload.
| Step | Action | Why |
|---|---|---|
| 1 | Find the app's exact bundle ID in App Store Connect | It is your source of truth |
| 2 | Match CFBundleIdentifier in Xcode to it exactly | Case-sensitive, no suffix |
| 3 | Align Fastlane app_identifier and Expo ios.bundleIdentifier | Tool config drift is common |
| 4 | Confirm the right target and scheme are built | Extensions have their own IDs |
| 5 | Rebuild and re-upload | Produces a matching binary |
| 6 | If you truly need a new ID, create a new app record | Existing app IDs are immutable |
The most important step is the first one: get the exact bundle identifier from App Store Connect and treat it as authoritative. Every other fix is just making your project and tools agree with that single value.
After it uploads: scan before you ship
Fixing ITMS-90054 gets your build accepted, but an accepted build is not the same as a secure one. The upload check confirms the bundle is structurally valid and correctly identified; it says nothing about whether the app ships an embedded secret, allows cleartext traffic, or leaves a debuggable flag on. Those reach users regardless of a correct bundle identifier.
A scanner like PTKD.com analyzes your .ipa and returns findings ordered by severity and mapped to OWASP MASVS, so you catch security issues before release. To be clear about the boundary: PTKD does not fix ITMS-90054 or any signing and identifier error, and it does not replace Apple's validation. It covers the security layer that an upload-time bundle check never looks at.
What to take away
- ITMS-90054 means your build's bundle identifier does not match the app's existing one, which Apple does not allow to change.
- The fix is almost always to revert CFBundleIdentifier to the exact original value, matching case and with no added suffix.
- Check every layer that sets it: Xcode target and build settings, Fastlane app_identifier, and Expo ios.bundleIdentifier.
- If you genuinely need a different identifier, create a new app record, accepting that it starts a fresh listing.
- After the upload succeeds, scan the build with PTKD.com, because a valid bundle is not the same as a secure one.
