Can a wildcard bundle ID cause this error?

Yes. App Store Connect does not accept wildcard identifiers, which contain an asterisk, for app records, tester invitations, or capabilities like Push Notifications. Apple requires an explicit reverse-DNS identifier such as com.acme.fitness for any app shipped through App Store Connect. Replace the wildcard with an explicit identifier in Certificates, Identifiers and Profiles, then update the bundle ID inside your Xcode target before retrying the allow action.

Does the error mean my Apple Developer Program membership has lapsed?

Not directly, but a lapsed membership can produce the same message because the team's app records become temporarily unreachable. Check the membership status at developer.apple.com/account. If the renewal date has passed, renew first, wait for the team status to refresh, then retry. If the membership is current, the error is almost certainly a team or bundle ID mismatch rather than a billing problem.

Will deleting and recreating the app record fix it?

Rarely, and the cost is high. Deleting an app record in App Store Connect releases the bundle ID for reuse only after a long retention period, often months, during which no other team can claim it. Try the team and bundle ID alignment fixes first. Reserve recreating the record for cases where the original was created under a personal team and the original team cannot transfer it.

Why did this error appear right after I accepted a transfer from another team?

App transfers can take several days during which the app record sits in a transitional state. Neither the originating nor the receiving team can fully act on the app while the transfer is in flight. The 'does not exist' message during that window is expected. Wait for the transfer to complete, refresh the team in Xcode Settings, and retry. Re-uploading a build before the transfer completes will fail.

Does this error affect TestFlight invitations for external testers?

Yes. External tester invitations rely on the same Team ID and bundle ID lookup. An external group can only contain testers added to a build that has been approved by TestFlight App Review, and that approval is recorded against the team that owns the app. A mismatch on any of the three identifiers will block the invitation with the same generic 'does not exist' message.

How do I fix 'the app you are attempting to allow does not exist'?

The error 'the app you are attempting to allow does not exist' surfaces in App Store Connect, Xcode, and the App Store Connect API at the exact moment you try to invite a tester, register a device, or upload a build. It almost always means the bundle ID, the Team ID, or the App Store Connect app record are out of alignment, not that your app has been deleted.

Short answer

The short answer is that this error fires when the tool performing the lookup, whether Xcode, the App Store Connect web UI, or a fastlane lane, cannot find an app record under the team you are signed into that matches the bundle ID in the request. App records on Apple's side are scoped to one team and one explicit bundle ID, so a wildcard, a duplicate, or a stale Team ID returns a 'does not exist' response even when the app exists under a different team.

What you should know

The error is a lookup failure, not a deletion notice. Your app record probably still exists, under a different team or with a different bundle ID.
Bundle ID matching is case-sensitive. com.acme.App and com.acme.app are treated as two different identifiers inside Apple's systems.
Wildcard bundle IDs cannot be allowed. App Store Connect requires an explicit identifier before any tester, device, or build action will resolve.
Team ID drives the lookup scope. Signing into Xcode with a personal team while the app sits under a company team produces the same error.
App Store Connect API keys are team-scoped. A key issued by one team cannot resolve an app record in another, even with admin credentials.
Managed Apple Accounts in reserved domains are blocked from TestFlight. Apple confirms this restriction in its TestFlight Help pages.

What does 'the app you are attempting to allow does not exist' actually mean?

The short answer is that the message is generic. It can fire inside App Store Connect when you try to add a tester, inside Xcode when you press Register on a device, or inside the App Store Connect API when a fastlane produce or pilot lane runs. In each case, the underlying lookup is the same: the service receives a Team ID and bundle ID pair and asks the App Store Connect backend whether a matching app record exists under that pairing.

The mechanism is simple. Every app record on Apple's side carries one owning Team ID, one explicit bundle ID, and one App Store Connect identifier. According to Apple's documentation on adding internal testers, the team owning the app is the scope for every TestFlight, build, and tester action. If the pair you submit does not match a record under your active team, the system returns a generic 'does not exist' message rather than a more specific error.

That shape is why the same message can mean six different underlying problems. Treat it as a class of failures rather than a single fault. The fix is always to find which of the variables (Team ID, bundle ID, account, app record, API key) is wrong.

Why does this error usually trace back to a team ID mismatch?

The short answer is that most Apple developers belong to more than one team, and Xcode silently picks the last team used. The Team ID identifies the account that owns the app on Apple's side. When you switch to a contractor team, a client team, or your personal team without updating the Signing and Capabilities tab in Xcode, the bundle ID resolves under a team that does not own it. The lookup returns 'does not exist' because, from the active team's perspective, that is the truth.

Mechanism: Xcode reads the Team selector in Signing and Capabilities, takes the bundle ID from the target settings, and asks App Store Connect to register or allow under that combination. If the team you selected has no record of com.acme.fitness, the answer is no.

Three patterns repeat in the Apple Developer Forums thread on bundle ID registration:

The Apple ID logged into Xcode is on multiple teams; Xcode defaulted to the wrong one.
The app was transferred from one team to another, but Xcode still has the old Team ID cached in Settings.
The bundle ID is registered in the new team while the Capabilities (Push Notifications, App Groups, iCloud) still reference the old team's identifiers.

This pattern usually only applies to Apple IDs that belong to more than one team. A single-team account hitting this error is more likely to be in the bundle ID or app record bucket below.

How do I check whether the bundle ID is registered in the right developer account?

The short answer is to open developer.apple.com/account, switch to the team that owns the app, and look inside Certificates, Identifiers and Profiles. If the bundle ID is not in the Identifiers list under that team, the error will fire no matter what else you change in Xcode.

The steps look like this:

Sign in at developer.apple.com/account.
Use the team picker in the top right to confirm you are inside the team that should own the app.
Open Identifiers and search for the explicit bundle ID (no wildcards).
If it is missing, register it. If it appears under a different team, that is the mismatch.

Apple's own forum threads on bundle ID registration consistently show that the second most common cause of this error is a bundle ID registered in a personal account while the app record lives in a company account. Both accounts can be linked to the same Apple ID, which makes the mistake easy to make and hard to spot.

Even with the correct bundle ID, an account that has 'limited app access' will not see the underlying app record. If you are in that position, ask the Account Holder to grant you the App Manager role for the specific app, as described in Apple's role permissions reference.

What if the app record looks correct but Xcode still rejects it?

The short answer is to clear the Xcode account cache, delete provisioning profiles, and rebuild the signing chain from scratch. The error often persists after the underlying mismatch is fixed because Xcode and the App Store Connect API both cache (team, bundle ID, app ID) tuples and serve the stale cache for a while.

A reliable rebuild sequence:

In Xcode, go to Settings, Accounts. Remove the Apple ID, then add it back. This forces Xcode to re-pull the list of teams.
In Finder, open ~/Library/MobileDevice/Provisioning Profiles/ and delete every .mobileprovision file. Xcode regenerates the profiles it actually needs on the next build.
In your project, set Signing to Automatic, pick the correct team, and let Xcode register the bundle ID fresh against that team.
If you use fastlane, delete the temporary keychain under ~/Library/Keychains/ or run fastlane match nuke development and re-run match against the correct team.

For the App Store Connect API path, revoke and re-issue the API key inside the team that owns the app, then update the issuer ID and key ID inside your fastlane Appfile or CI variables.

This rebuild matters because the OWASP Mobile Application Security Testing Guide treats the signing identity as part of the integrity chain that a reviewer can verify. PTKD.com (https://ptkd.com) and other pre-submission scanners check that the signing team in the IPA matches the team that owns the App Store Connect record; a mismatch is one of the first flags they raise during a static analysis pass.

How do I fix it inside a fastlane, Xcode Cloud, or GitLab CI pipeline?

The short answer is that the fix is the same as in Xcode, but the inputs are environment variables rather than GUI selectors. Find the variable that holds the Team ID, the variable that holds the bundle ID, and the API key file. Confirm all three are scoped to the same team.

For fastlane, the canonical fix steps are:

In your Appfile, set team_id and apple_id to the team and Apple ID that owns the app record.
Pass an app_identifier that exactly matches the explicit bundle ID registered under that team.
Use an App Store Connect API key issued by that team. The match and pilot lanes will default to a different team if no key is supplied.
Run fastlane spaceship or fastlane produce with --verbose to see which team the call resolves under.

For Xcode Cloud, the team is set during workflow creation and cannot be changed without recreating the workflow. If the workflow was originally set up under the wrong team, the only path is to recreate it.

For GitLab CI or GitHub Actions, the Team ID typically lives in a CI variable named APPLE_TEAM_ID, FASTLANE_TEAM_ID, or similar. Confirm the value matches the issuer ID of your App Store Connect API key.

Tool	Where the Team ID lives	How to fix the mismatch
Xcode	Signing and Capabilities, Team dropdown	Switch the dropdown, regenerate profiles
Fastlane	Appfile and `FASTLANE_TEAM_ID` env var	Edit Appfile, refresh API key
Xcode Cloud	Workflow settings, fixed at creation	Recreate the workflow under the correct team
App Store Connect API	API key issuer ID and scope	Revoke and reissue the key under the correct team
GitLab CI or GitHub Actions	CI variable	Update the variable, rotate the API key

What to watch out for

Several edge cases produce the same 'does not exist' message and waste a full day if you do not catch them early.

The app is in the middle of a transfer. App transfers between teams take several days. During the transfer, neither team can fully act on the app record. Wait for the transfer to complete before retrying any tester or build action.
The app was rejected and removed. A removed app record looks gone to Xcode but may still be recoverable in App Store Connect under the 'Removed' filter inside My Apps. Restore it before retrying.
You are testing with a Managed Apple Account in a reserved domain. Per Apple's TestFlight Help for external testers, these accounts cannot accept invitations or run builds, and the error message they trigger is generic.
The Apple Developer Program membership has lapsed. A team with an expired membership cannot allow any new app actions; renew first, then retry.
You are mixing development and distribution profiles. A development profile cannot allow an action that requires a distribution provisioning profile, and the system reports it as a missing app record rather than a profile mismatch.

A common myth in builder communities is that the error means Apple has flagged the app. That reading is wrong. The error is a lookup failure, and filing a Resolution Center reply or escalating to App Review will not move it. Fix the identifiers and the message disappears.

Key takeaways

Treat the error as a Team ID, bundle ID, account, app record, and API key alignment problem rather than as a sign that anything has been deleted or banned.
Confirm the bundle ID is explicit, case-correct, and registered inside the team that owns the App Store Connect record before retrying any tester or build action.
Cache invalidation is part of the fix; clearing provisioning profiles and re-adding the Apple ID in Xcode Settings resolves a meaningful share of cases that look stuck after the underlying mismatch is corrected.
For CI pipelines, the App Store Connect API key issuer ID is the single most useful signal for confirming which team a call is actually running under.
Some teams outsource the pre-submission integrity check, including the signing-team match against the App Store Connect record, to platforms like PTKD.com (https://ptkd.com); it is one way to catch the mismatch before TestFlight ever rejects the invite.