Bundle ID vs App ID: Team ID, Certificates and Profiles
A Bundle ID names your app, an App ID is Team ID + Bundle ID + capabilities; a profile ties App ID, certificate and devices. One table plus error fixes.
Bundle ID vs App ID comes down to this: the Bundle ID uniquely identifies your app in the project, while the App ID is the record you register with Apple (Team ID + Bundle ID + allowed capabilities). The Team ID identifies your development team, and the certificate proves who signed the app. The provisioning profile ties the App ID, certificates, devices and capabilities together, deciding which certificate can sign the app and which phones can install it. Nearly every signing error means two of these don’t match, so read the overview table first, then use the error table to troubleshoot. Apple rules are as of October 2026.
What are the Team ID, Bundle ID, App ID, certificate and profile?
| Name | What it is | What it looks like | Where to find it | File |
|---|---|---|---|---|
| Team ID | The team identifier Apple assigns to developer program members | 10 characters, such as ABCDE12345 |
Membership details on the Account page of the developer website | No separate file |
| Bundle ID | The app’s unique identifier in the project | Reverse domain, such as com.example.myapp |
The project’s PRODUCT_BUNDLE_IDENTIFIER |
Written into Info.plist |
| App ID | The app identifier registered with Apple, with a list of capabilities | ABCDE12345.com.example.myapp or ABCDE12345.com.example.* |
Identifiers page in Certificates, Identifiers & Profiles | No separate file |
| Certificate | Proves the signer’s identity. You hold the private key | Apple Development, Apple Distribution | Certificates page | .cer (no private key), .p12 (with private key) |
| Provisioning profile | The authorization file that ties App ID, certificates, devices and capabilities together | Development, Ad Hoc, App Store Connect, In-House | Profiles page | .mobileprovision |
For Apple’s definition of the Team ID, see the glossary entry Team ID.
How do the Bundle ID and App ID fit together?
1Provisioning profile (.mobileprovision)
2├─ Team ID
3├─ App ID ─────── Team ID prefix + Bundle ID (or wildcard com.example.*)
4│ └─ Enabled capabilities: push, App Groups, iCloud...
5├─ Certificates ─ One or more. Signing needs the .p12 for one of them
6├─ Device UDIDs ─ Development and Ad Hoc types only
7└─ Expiration date
Keep three matching rules in mind and every signing problem has a direction.
- The project’s Bundle ID must match the App ID in the profile. An explicit App ID must match exactly. A wildcard App ID must share the prefix.
- The .p12 you sign with must be one of the certificates selected in the profile. If you switch certificates, regenerate the profile.
- The phone you install on must be in the profile’s device list. This applies to Development and Ad Hoc profiles only.
A profile locks all of this in at the moment it’s generated. After you register a new device, enable a new capability on the App ID or switch certificates, go back to the Profiles page, edit the profile, save it and download it again. Apple’s Edit, download, or delete provisioning profiles states that you need to regenerate a profile when you turn app services on or off or when it expires.
Where do you find and use each piece?
Team ID
The Team ID is a 10-character string that belongs to members of the paid Apple Developer Program or the Apple Developer Enterprise Program. Sign in to developer.apple.com/account and find it under Membership details. A free Apple Account doesn’t have one.
The matching build setting in the project is DEVELOPMENT_TEAM. The TeamIdentifier in a profile and the App ID prefix are usually the same value. If you belong to several teams, each team has its own Team ID, and you must sign with a certificate and profile from the same team.
Bundle ID
The Bundle ID is set in the project and becomes CFBundleIdentifier in Info.plist after the build. Your app record in App Store Connect is also tied to it, and once you’ve uploaded a build you can’t change it. Decide on it before you create the app record.
Each extension target has its own Bundle ID, which must start with the main app’s Bundle ID plus a dot. If the main app is com.example.myapp, the widget is com.example.myapp.widget. Every extension needs its own App ID and provisioning profile.
App ID: explicit and wildcard
Apple’s Register an App ID help page describes two kinds. An explicit App ID is for a single app, and a wildcard App ID is for a set of apps. The capabilities enabled on an App ID are an allowlist, and the app can only use what’s on it.
| Explicit App ID | Wildcard App ID | |
|---|---|---|
| Format | com.example.myapp |
com.example.* |
| Covers | One Bundle ID | Every Bundle ID with the same prefix |
| Capabilities | Push, App Groups, iCloud, Sign in with Apple and more | Capabilities that need an explicit App ID are grayed out on the registration page |
| Upload to App Store Connect | Yes | No. Apple requires app records to use an explicit App ID |
| Good for | Apps you publish, apps that use capabilities | Development, small tools that use no special capabilities |
The publishing requirement is stated in Apple’s Create an App Store provisioning profile. Uploading to App Store Connect needs an app record registered with an explicit App ID. If you plan to publish an app, register an explicit App ID from the start.
Certificates
Certificates come in development and distribution types. Apple’s Certificates overview says development certificates belong to individuals and distribution certificates belong to the team, and only the Account Holder or an Admin can create distribution certificates.
- Apple Development runs and debugs apps on devices. Each person on the team can have their own.
- Apple Distribution uploads to App Store Connect or signs builds for specific test devices (Ad Hoc). The team shares one, so don’t request one per person.
Signing needs a .p12 with the private key. The .cer you download from the portal contains only the certificate, so you can’t sign with it alone. For the full steps to generate a CSR and build a .p12 on Windows, see Get an iOS certificate, p12 and provisioning profile on Windows.
The Apple Push Notification service SSL certificate lets your server send push notifications. It doesn’t sign apps and is separate from the signing certificates in this article.
How do the four profile types differ?
| Development | Ad Hoc | App Store Connect | In-House | |
|---|---|---|---|---|
| Purpose | Development and debugging | Send test builds directly to a small group of testers | Upload to App Store Connect and install through TestFlight and the App Store | Internal use by employees of an organization |
| Certificates | One or more development certificates | One distribution certificate | One distribution certificate | The enterprise account’s distribution certificate |
| Device list | Yes, register UDIDs | Yes, register UDIDs | No | No |
| Install directly on a phone | Yes, listed devices only | Yes, listed devices only | No | Within the organization only |
| Account | Apple Developer Program | Apple Developer Program | Apple Developer Program | Apple Developer Enterprise Program only |
Sources are Apple’s Create a development provisioning profile, Create an ad hoc provisioning profile and the App Store profile page linked above.
A few more details.
- Creating the first three profile types manually in the portal requires the Account Holder or Admin role.
- A Development profile can include the development certificates of everyone on the team, so the whole team can share one file.
- Ad Hoc and Development profiles both use device slots, up to 100 devices per device type per membership year. With many testers, use TestFlight instead and skip collecting UDIDs.
- The In-House type belongs only to the Enterprise Program. Apple allows it only for internal use by the organization’s employees, not for public distribution, and this article doesn’t cover it further.
Which mismatch causes which signing error?
| What doesn’t match | Typical error | Fix |
|---|---|---|
| Bundle ID and the profile’s App ID | Provisioning profile "…" has app ID "…", which does not match the bundle ID "…" |
Generate a profile for the Bundle ID in the error. See the signing errors tutorial |
| An extension’s Bundle ID has no profile | No profiles for 'com.example.myapp.widget' were found |
Register an App ID and generate a profile for the extension. See the signing errors tutorial |
| Certificate and profile | Provisioning profile "…" doesn't include signing certificate "…" |
Edit the profile and select the current certificate. See the signing errors tutorial |
| Certificate type or team the project asks for | No signing certificate matching '…' found |
Add a .p12 of the right type from the right team. See the signing errors tutorial |
| Entitlements and the App ID’s capabilities | doesn't include the Push Notifications capability |
Enable the capability on the App ID, then regenerate the profile. See the signing errors tutorial |
| Phone and the profile’s device list | 0xe8008015 or doesn't include the currently selected device |
Register the UDID, then download the profile again. See device not registered |
| Team of the old version on the phone and the new build | MismatchedApplicationIdentifierEntitlement |
Delete the old version, then install again. See the signing errors tutorial |
| Profile type and install method | A build signed with an App Store profile fails to install on a phone | Test with Development or Ad Hoc, or go through TestFlight |
Check a profile’s contents on Windows
Decode the profile with the OpenSSL that comes with Git for Windows, then check each item against the rules above.
1& "C:\Program Files\Git\mingw64\bin\openssl.exe" smime -inform DER -verify -noverify -in .\keychain\MyApp_Dev.mobileprovision -out profile.plist
| What to check | Key in profile.plist |
|---|---|
| Team ID | TeamIdentifier |
| Whether the App ID matches the Bundle ID | Entitlements > application-identifier |
| Enabled capabilities | The other keys under Entitlements, such as aps-environment |
| Devices | ProvisionedDevices |
| Expiration date | ExpirationDate |
To see the resolved Bundle ID of each target in the project, run the command below.
1kxbuild project info .\MyApp.xcodeproj
Where do certificates and profiles go in KXBuild?
When you build with KXBuild on Windows or Linux, put the .p12, .mobileprovision and the password file password.properties into a keychain folder. Certificates and signing has the full rules.
<project>/keychain/applies to that project only.KXBUILD_HOME/keychain/is shared by all projects. By default it’s%USERPROFILE%\kxbuild\keychain\on Windows and~/kxbuild/keychain/on WSL, Linux and macOS.
Files from both places are used together. For an app with a widget, the development and App Store files look like this side by side.
1keychain\
2├─ development.p12
3├─ distribution.p12
4├─ MyApp_Dev.mobileprovision
5├─ MyAppWidget_Dev.mobileprovision
6├─ MyApp_AppStore.mobileprovision
7├─ MyAppWidget_AppStore.mobileprovision
8└─ password.properties
password.properties has one line per certificate in the form filename=password.
1development.p12=your-password
2distribution.p12=your-password
At build time the files are picked according to the project’s signing settings. CODE_SIGN_IDENTITY decides between a development and a distribution certificate, and DEVELOPMENT_TEAM decides the team. Automatic signing matches profiles by Bundle ID and team, and manual signing looks up the profile named in PROVISIONING_PROFILE_SPECIFIER. See how certificates are selected. All of these are in the Identity and Signing groups on the General page of the Project Settings Editor.
FAQ
Are the Bundle ID and the App ID the same thing?
No. The Bundle ID is set in the project and identifies the app. The App ID is a record registered with Apple, made of the Team ID prefix plus the Bundle ID, and it carries the list of enabled capabilities. Profiles reference the App ID, which must match the project’s Bundle ID.
Where do I find my Team ID?
Sign in to the Apple Developer website and look under Membership details on the Account page. It’s a 10-character string. You can also decode a provisioning profile and read the TeamIdentifier field.
Can a wildcard App ID be used on the App Store?
No. Apple requires app records uploaded to App Store Connect to use an explicit App ID. Wildcard App IDs also can’t enable most capabilities, such as push and App Groups, so they’re only suitable during development.
What’s inside a provisioning profile?
The team, the App ID, the certificates allowed to sign, the enabled capabilities and the expiration date. Development and Ad Hoc profiles also contain the UDIDs of devices allowed to install. If any of these changes, regenerate and download the profile again.
Do I need new certificates when I switch to a new computer?
No. Copy the .p12 with its private key and the matching .mobileprovision into the keychain folder on the new computer, then fill in password.properties. You only need to request a new certificate if you have the .cer but not the private key.