Code signing uses various different identifier types, and I’ve seen a lot of folks confused as to which is which. This post is my attempt to clear up that confusion.
If you have questions or comments, put them in a new thread, using the same topic area and tags as this post.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Code Signing Identifiers Explained
An identifier is a short string that uniquely identifies a resource. Apple’s code-signing infrastructure uses identifiers for various different resource types. These identifiers typically use one of a small selection of formats, so it’s not always clear what type of identifier you’re looking at. This post lists the common identifiers used by code signing, shows the expected format, and gives references to further reading.
Unless otherwise noted, any information about iOS applies to iOS, iPadOS, tvOS, visionOS, and watchOS.
Formats
The code-signing identifiers discussed here use one of two formats:
10-character This is composed of 10 ASCII characters. For example, Team IDs use this format, as illustrated by the Team ID of one of Apple’s test teams: Z7P62XVNWC.
Reverse-DNS This is composed of labels separated by a dot. For example, bundle IDs use this format, as illustrated by the bundle ID of the test app associated with this post: com.example.tn3NNNapp.
The Domain Name System has strict rules about domain names, in terms of overall length, label length, text encoding, and case sensitivity. The reverse-DNS identifiers used by code signing may or may not have similar limits. When in doubt, consult the documentation for the specific identifier type.
Reverse-DNS names are just a convenient way to format a string. You don’t have to control the corresponding DNS name. You can, for example, use com.<SomeCompany>.my-app as your bundle ID regardless of whether you control the <SomeCompany>.com domain name. To securely associate your app with a domain, use associated domains. For more on that, see Supporting associated domains.
IMPORTANT Don’t use com.apple. in your reverse-DNS identifiers. That can yield unexpected results.
Identifiers
The following table summarises the identifiers covered below:
Name | Format | Example | Notes
---- | ------ | ------- | -----
Team ID | 10-character | `Z7P62XVNWC` | Identifies a developer team
User ID | 10-character | `UT376R4K29` | Identifies a developer
Team Member ID | 10-character | `EW7W773AA7` | Identifies a developer in a team
Bundle ID | reverse-DNS | `com.example.tn3NNNapp` | Identifies an app
App ID prefix | 10-character | `Z7P62XVNWC` | Part of an App ID
| | `VYRRC68ZE6` |
App ID | mixed | `Z7P62XVNWC.com.example.tn3NNNNapp` | Connects an app and its provisioning profile
| | `VYRRC68ZE6.com.example.tn3NNNNappB` |
Code-signing identifier | reverse-DNS | `com.example.tn3NNNapp` | Identifies code to macOS
| | `tn3NNNtool` |
App group ID | reverse DNS | `group.tn3NNNapp.shared` | Identifies an app group
| reverse DNS | `Z7P62XVNWC.tn3NNNapp.shared` | Identifies an macOS-style app group
As you can see, there’s no clear way to distinguish a Team ID, User ID, Team Member ID, and an App ID prefix. You have to determine that based on the context. In contrast, you choose your own bundle ID and app group ID values, so choose values that make it easier to keep things straight.
Team ID
When you set up a team on the Developer website, it generates a unique Team ID for that team. This uses the 10-character format. For example, Z7P62XVNWC is the Team ID for an Apple test team.
When the Developer website issues a certificate to a team, or a user within a team, it sets the Subject Name > Organisational Unit field to the Team ID.
When the Developer website issues a certificate to a team, as opposed to a user in that team, it embeds the Team ID in the Subject > Common Name field. For example, a Developer ID Application certificate for the Team ID Z7P62XVNWC has the name Developer ID Application: <TeamName> (Z7P62XVNWC).
### User ID
When you first sign in to the Developer website, it generates a unique User ID for your Apple Account. This User ID uses the 10-character format. For example, UT376R4K29 is the User ID for an Apple test user.
When the Developer website issues a certificate to a user, it sets the Subject Name > User ID field to that user’s User ID. It uses the same value for that user in all teams.
Team Member ID
When you join a team on the Developer website, it generates a unique Team Member ID to track your association with that team. This uses the 10-character format. For example, EW7W773AA7 is the Team Member ID for User ID UT376R4K29 in Team ID Z7P62XVNWC.
When the Developer website issues a certificate to a user on a team, it embeds the Team Member ID in the Subject > Common Name field. For example, an Apple Development certificate for User ID UT376R4K29 on Team ID Z7P62XVNWC has the name Apple Development: <UserName> (EW7W773AA7).
IMPORTANT This naming system is a common source of confusion. Developers see this ID and wonder why it doesn’t match their Team ID. The advantage of this naming scheme is that each certificate gets a unique name even if the team has multiple members with the same name. The John Smiths of this world appreciate this very much.
Bundle ID
A bundle ID is a reverse-DNS identifier that identifies a single app throughout Apple’s ecosystem. For example, the test app associated with this post has a bundle ID of com.example.tn3NNNapp.
If two apps have the same bundle ID, they are considered to be the same app.
Bundle IDs have strict limits on their format. For the details, see CFBundleIdentifier.
If your macOS code consumes bundle IDs — for example, you’re creating a security product that checks the identity of code — be warned that not all bundle IDs conform to the documented format. And non-bundled code, like a command-line tool or dynamic library, typically doesn’t have a bundle ID. Moreover, malicious code might use arbitrary bytes as the bundle ID, bytes that don’t parse as either ASCII or UTF-8.
WARNING On macOS, don’t assume that a bundle ID follows the documented format, is UTF-8, or is even text at all. Do not assume that a bundle ID that starts with com.apple. represents Apple code.
A better way to identify code on macOS is with its designated requirement, as explained in TN3127 Inside Code Signing: Requirements.
On iOS this isn’t a problem because the Developer website checks the bundle ID format when you register your App ID.
App ID prefix
An App ID prefix forms part of an App ID (see below). It’s a 10-character identifier that’s either:
The Team ID of the app’s team
A unique App ID prefix
Note Historically a unique App ID prefix was called a Bundle Seed ID.
A unique App ID prefix is a 10-character identifier generated by Apple and allocated to your team, different from your Team ID. For example, Team ID Z7P62XVNWC has been allocated the unique App ID prefix of VYRRC68ZE6. Unique App ID prefixes are effectively deprecated:
You can’t create a new App ID prefix. So, unless your team is very old, you don’t have to worry about unique App ID prefixes at all.
If a unique App ID prefix is available to your team, it’s possible to create a new App ID with that prefix.
But doing so prevents that app from sharing state with other apps from your team.
Unique app ID prefixes are not supported on macOS.
If your app uses a unique App ID prefix, you can request that it be migrated to use your Team ID by contacting Apple > Developer > Contact Us. If you app has embedded app extensions that also use your unique App ID prefix, include all those App IDs in your migration request.
WARNING Before migrating from a unique App ID prefix, read App ID Prefix Change and Keychain Access.
App ID
An App ID ties your app to its provisioning profile. Specifically:
You allocate an App ID on the Developer website.
You sign your app with an entitlement that claims your App ID.
When you launch the app, the system looks for a profile that authorises that claim.
App IDs are critical on iOS. On macOS, App IDs are only necessary when your app claims a restricted entitlement. See TN3125 Inside Code Signing: Provisioning Profiles for more about this.
App IDs have the format <Prefix>.<BundleOrWildcard>, where:
<Prefix> is the App ID prefix, discussed above.
<BundleOrWildcard> is either a bundle ID, for an explicit App ID, or a wildcard, for a wildcard App ID. The wildcard follows bundle ID conventions except that it must end with a star (*).
For example:
Z7P62XVNWC.com.example.tn3NNNNapp is an explicit App ID for Team ID Z7P62XVNWC.
Z7P62XVNWC.com.example.* is a wildcard App ID for Team ID Z7P62XVNWC.
VYRRC68ZE6.com.example.tn3NNNNappB is an explicit App ID with the unique App ID prefix of VYRRC68ZE6.
Provisioning profiles created for an explicit App ID authorise the claim of just that App ID. Provisioning profiles created for a wildcard App ID authorise the claim of any App IDs whose bundle ID matches the wildcard, where the star (*) matches zero or more arbitrary characters.
Wildcard App IDs are helpful for quick tests. Most production apps claim an explicit App ID, because various features rely on that. For example, in-app purchase requires an explicit App ID.
Code-signing identifier
A code-signing identifier is a string chosen by the code’s signer to uniquely identify their code.
IMPORTANT Don’t confuse this with a code-signing identity, which is a digital identity used for code signing. For more about code-signing identities, see TN3161 Inside Code Signing: Certificates.
Code-signing identifiers exist on iOS but they don’t do anything useful. On iOS, all third-party code must be bundled, and the system ensures that the code’s code-signing identifier matches its bundle ID.
On macOS, code-signing identifiers play an important role in code-signing requirements. For more on that topic, see TN3127 Inside Code Signing: Requirements.
When signing code, see Creating distribution-signed code for macOS for advice on how to select a code-signing identifier.
If your macOS code consumes code-signing identifiers — for example, you’re creating a security product that checks the identity of code — be warned that these identifiers look like bundle IDs but they are not the same as bundle IDs. While bundled code typically uses the bundled ID as the code-signing identifier, macOS doesn’t enforce that convention. And non-bundled code, like a command-line tool or dynamic library, often uses the file name as the code-signing identifier. Moreover, malicious code might use arbitrary bytes as the code-signing identifier, bytes that don’t parse as either ASCII or UTF-8.
WARNING On macOS, don’t assume that a code-signing identifier is a well-formed bundle ID, UTF-8, or even text at all. Don’t assume that a code-signing identifier that starts with com.apple. represents Apple code.
A better way to identify code on macOS is with its designated requirement, as explained in TN3127 Inside Code Signing: Requirements.
App Group ID
An app group ID identifies an app group, that is, a mechanism to share state between multiple apps from the same team. For more about app groups, see App Groups Entitlement and App Groups: macOS vs iOS: Working Towards Harmony.
App group IDs use two different forms of reverse-DNS identifiers:
iOS-style This has the format group.<GroupName>, for example, group.tn3NNNapp.shared.
macOS-style This has the format <TeamID>.<GroupName>, for example, Z7P62XVNWC.tn3NNNapp.shared.
The first form originated on iOS but is now supported on macOS as well. The second form is only supported on macOS.
iOS-style app group IDs must be registered with the Developer website. That ensures that the ID is unique and that the <GroupName> follows bundle ID rules.
macOS-style app group IDs are less constrained. When choosing such a macOS-style app group ID, follow bundle ID rules for the group name.
If your macOS code consumes app group IDs, be warned that not all macOS-style app group IDs follow bundle ID format. Indeed, malicious code might use arbitrary bytes as the app group ID, bytes that don’t parse as either ASCII or UTF-8.
WARNING Don’t assume that a macOS-style app group ID follows bundle ID rules, is UTF-8, or is even text at all. Don’t assume that a macOS-style app group ID where the group name starts with com.apple. represents Apple in any way.
Some developers use app group IDs of the form <TeamID>.group.<GroupName>. There’s nothing special about this format. It’s just a macOS-style app group ID where the first label in the group name just happens to be group
Starting in Feb 2025, iOS-style app group IDs are fully supported on macOS. If you’re writing new code that uses app groups, use an iOS-style app group ID. This allows sharing between different product types, for example, between a native macOS app and an iOS app running on the Mac.
Revision History
2026-01-06 First posted.
