The "bundle identifier already in use" error during an iOS app handover almost always means the App ID is already registered to a team, and Apple reserves each bundle identifier globally to the team that first registered it. The usual trap is trying to register or build the app under that bundle ID on the destination account before the transfer happens, which Apple will not allow. The fix is to run the app transfer itself, which moves the App ID to the new account, rather than recreating it. Do not pre-register the bundle ID on the receiving side.
Short answer
Apple reserves every bundle identifier to the team that first registered its App ID, so no other account can register or build under it, as Apple's app transfer documentation and developer forums confirm. During a handover, the error appears when the receiving account tries to create the same App ID before the transfer, or when the app does not yet meet Apple's transfer criteria. The safe path is to leave the bundle ID untouched on the destination, run the official app transfer from the source account, and only then generate fresh certificates and provisioning profiles on the new team. Deleting the bundle ID does not free it, and the receiving team must re-sign after the move.
What causes the "bundle identifier already in use" error?
The error means the exact bundle identifier already has an App ID registered to some team, and Apple will not let a second team register or use it. In a handover, that team is usually the current owner, so the receiving developer sees the error the moment they try to create the App ID or upload a build under it.
There are a few distinct triggers. The most common is the receiving account pre-registering the App ID before the transfer, which collides with the owner's existing registration. Others include the app not yet meeting Apple's transfer criteria, a wildcard App ID that overlaps, or an old registration in a personal team that someone forgot about. Each points to the same root cause: the bundle ID is reserved elsewhere.
Why bundle IDs are globally reserved
When a team creates an App ID, the bundle identifier is reserved to that team, and no other team can register an App ID for it. This is a global, Apple-wide reservation, not a per-account setting, which is why a bundle ID that looks free from your side can still be taken. It is the mechanism that ties one app to one owner.
Crucially, deleting the App ID does not release the bundle identifier for another account to reuse, and a bundle ID cannot simply be re-used by a different team without a formal transfer. This is by design: it prevents two developers from ever claiming the same app identity. For a handover, it means the only correct way to move a bundle ID is the app transfer flow, which carries the App ID with it.
The error-cause matrix
Matching the exact symptom to its cause is the fastest way to the right fix. The table below covers the common cases during a handover.
| Symptom | Cause | Fix |
|---|---|---|
| Error creating the App ID on the new account | Bundle ID pre-registered before transfer | Do not pre-register, run the transfer |
| Error uploading a build on the new account | App ID still owned by the source team | Complete the app transfer first |
| Transfer option is unavailable | App does not meet Apple's transfer criteria | Resolve agreements, entitlements, pending reviews |
| Bundle ID "taken" but you cannot find it | Registered in a personal or old team | Locate the owning team, then transfer |
| Signing fails after the transfer | Profiles and certificates did not transfer | Regenerate signing assets on the new team |
Reading the matrix first prevents the classic mistake of trying to "clear" the bundle ID on the destination, which cannot work because the reservation lives with the source team until the transfer completes.
Which certificates, profiles, and keys are involved?
An app transfer moves the app record and its App ID, but it does not move your signing assets. Distribution certificates, provisioning profiles, and push notification keys are tied to the team, so after the transfer the receiving team must create its own. This is why a build that signed cleanly for the old owner will fail to sign for the new one until fresh assets exist.
Two items deserve special attention. Provisioning profiles reference both the App ID and a certificate, so a stale profile on the receiving side will not match and must be regenerated. And capabilities backed by external identifiers, such as push notification keys or merchant identifiers, need to be set up again in the new account, because those credentials do not travel with the app.
Checks: Xcode, the developer portal, Fastlane, and Expo EAS
Before and after the transfer, verify the state in each tool you use. In Xcode's Signing and Capabilities tab, confirm the bundle identifier and the selected team, and let it show you whether a matching provisioning profile exists. In the developer portal under Identifiers, check whether the App ID exists and, importantly, which team owns it.
For automation, the same truth surfaces through the CLI. Fastlane's produce action fails when the bundle ID is already registered, which is a useful early signal, and match or sigh will regenerate signing assets for the new team once the transfer is done. For Expo, check the ios.bundleIdentifier in your app config and re-run EAS credential setup so EAS provisions certificates and profiles under the new account. Whichever tool you use, the fix is never to force the bundle ID; it is to align the tool with the account that actually owns it.
The safe transfer and retry path
When you hit the error, stop and follow an ordered path rather than deleting or recreating identifiers. The checklist below moves from verification to a clean re-sign.
| Step | Action | Why |
|---|---|---|
| 1 | Identify which account owns the App ID | Confirms the source of the reservation |
| 2 | Do not pre-register the bundle ID on the destination | Avoids the collision entirely |
| 3 | Verify the app meets Apple's transfer criteria | Enables the transfer option |
| 4 | Run the app transfer, accept on the destination | Moves the App ID correctly |
| 5 | Generate new certificates and provisioning profiles | Signing assets do not transfer |
| 6 | Rebuild, scan, and rotate old secrets | A clean, secure handover |
The single most important rule is in the first two rows: do not pre-register the bundle ID on the destination, and confirm the app meets Apple's transfer criteria, because those two mistakes cause most handover failures. Everything after the transfer is routine signing setup.
After the transfer: re-sign and rotate secrets
Once the App ID lands in the new account, the receiving team regenerates certificates and provisioning profiles and rebuilds, and this is also the right moment to handle security. A handover often carries over secrets that belonged to the previous owner: API keys embedded in the app, tokens in the CI pipeline, or credentials for services the old team controlled. Leaving those in place hands the old owner ongoing access.
A scanner like PTKD.com analyzes the re-signed .ipa and returns findings ordered by severity and mapped to OWASP MASVS, so you can spot embedded secrets and insecure configurations that should be rotated as part of the handover. To be honest about the boundary: PTKD does not perform the app transfer, fix code signing, or rotate keys for you. It flags what needs attention, so the new owner does not inherit the old owner's secrets by accident.
How to prevent it next time
Most recurrences come from pre-registering identifiers or from unclear ownership. Never create the App ID on the receiving account ahead of a transfer; let the transfer carry it over. Agree in writing which account owns the bundle ID, and use reverse-DNS identifiers based on a domain you control so accidental collisions are unlikely.
For teams that transfer apps often, centralize signing so there is one source of truth. Fastlane match keeps certificates and profiles in a shared, version-controlled store, and EAS manages credentials for Expo projects. With a single system generating signing assets for the owning account, a handover becomes a transfer plus a credential refresh, not a scramble to untangle who registered what.
What to take away
- The error means the bundle identifier's App ID is already reserved to a team, and Apple reserves each one globally.
- During a handover, it usually means the receiving account tried to register the bundle ID before the transfer, so do not pre-register it.
- Run the official app transfer to move the App ID, then generate fresh certificates and provisioning profiles on the new team.
- Deleting a bundle ID does not free it, and signing assets do not transfer, so the new owner must re-sign.
- After the move, scan the re-signed build with PTKD.com to catch secrets that should be rotated in the handover.
