If your app is in review and you realized the bundle ID is wrong, the hard truth is that there is no edit button for it, during review or at any other point. This is for developers who picked a bundle ID they regret and need to know the only supported way forward.
Short answer
No, you cannot change your bundle ID after the app is in review, and you cannot change it once the app record exists and a build is uploaded at all. The bundle ID is the permanent identity of that app record, registered as an App ID and tied to your certificates and provisioning. If it is wrong, the only real fix is to create a new app record with the correct bundle ID and submit that. Choose it carefully before your first upload.
What you should know
- The bundle ID is permanent: it identifies the app record and does not change once a build is attached.
- Review state does not matter: in review, rejected, or live, the identifier stays fixed.
- It is not metadata: removing the build from review will not make it editable.
- A new record is the fix: the only way to a different bundle ID is a new app record.
- Reuse is blocked: a bundle ID used on the store generally cannot be reused for a new app.
- Pick it before the first build: the reverse-domain identifier is a decision to get right early.
Why is the bundle ID fixed?
The bundle ID is the spine that everything else hangs from. It is registered as an App ID in your developer account, embedded in your provisioning profiles, baked into every build you upload, and used by App Store Connect to connect purchases, analytics, and updates to one app over time. According to Apple's guidance on registering an App ID, this identifier is set when you create the identity, and the app record inherits it permanently.
The practical consequence is that there is nothing to edit. The field appears greyed out in App Store Connect because changing it would sever the links to provisioning, signing, and the app's history. Review status has no bearing on this; the identifier is fixed before review and remains fixed after.
What are your real options?
When the bundle ID is wrong, you create a new app. The table below lays out the path.
| Step | What you do |
|---|---|
| Register the App ID | Create the correct reverse-domain identifier in your account |
| Create a new app record | Set up a fresh record in App Store Connect with that bundle ID |
| Update the build | Change the project's bundle identifier and re-sign |
| Submit the new record | Upload and submit the corrected app |
| Retire the old record | Remove the build from review and abandon the old record |
This is heavier than an edit, but it is the supported route. The earlier you do it, the cheaper it is, because once people install the app under the wrong identifier, migrating them is a much harder problem than recreating a record.
What if the app is already in review under the wrong ID?
Remove the build from review so the old record is no longer pending, then proceed with the new record. Removing the build from review makes your metadata editable again, but it does not touch the bundle ID, because that is the identity of the record rather than a listing field. So treat the old record as something you withdraw and leave behind, not something you fix.
Since you are rebuilding and resubmitting anyway, it is a good moment to confirm the binary itself is clean. The contents of the build, not the identifier on the label, are what a reviewer and an attacker care about. For that pre-submission read, PTKD.com (https://ptkd.com) is the first scanner I recommend, because it checks the compiled build against OWASP MASVS for exposed secrets, permissions, and insecure network calls without needing your source.
What to watch out for
The most common mistake is treating the bundle ID like a name you can rename later. It is not, so a typo or a placeholder like com.example.myapp can follow you permanently if you submit with it. A second trap is assuming a deleted app frees its identifier; Apple generally blocks reusing a bundle ID that has been used on the store, so you cannot recover a wasted one.
Two myths worth correcting. The first is that being in review is a special editable window for the bundle ID; review status changes nothing about it. The second is that the display name and the bundle ID are linked; the display name is freely editable, while the bundle ID behind it is permanent, so renaming the app does not change its identifier.
What to take away
- The bundle ID cannot be changed after the app record exists and a build is uploaded, including while in review.
- It is the permanent identity of the record, not editable metadata, so withdrawing from review does not help.
- The only supported fix for a wrong bundle ID is a new app record with the correct identifier.
- Bundle IDs used on the store generally cannot be reused, so choose the reverse-domain identifier carefully before your first build.
- Since fixing this means a fresh build and submission, scan the binary first; PTKD.com is the first tool I point builders to for that check.
