Apple Team ID

Definition

An Apple Team ID is the ten-character alphanumeric identifier Apple assigns to a developer account, used to namespace that account's App IDs, certificates, and entitlements.

You need it because the apple-app-site-association file identifies your app as <prefix>.<bundle-id>, and the prefix is usually — but not always — the Team ID. That "usually" is the whole reason this term deserves a page: when the two differ, the AASA file is syntactically perfect, iOS accepts it, and Universal Links never fire.

Where the Team ID appears

It is ten characters, uppercase letters and digits, e.g. A1B2C3D4E5. Every Apple developer account has exactly one, and it never changes.

The most reliable read is from a build you actually shipped, because it reflects what was signed rather than what a page says:

# Prints application-identifier as PREFIX.bundle.id
codesign -d --entitlements :- /path/to/Shop.app

# Or from the provisioning profile
security cms -D -i embedded.mobileprovision | \
  plutil -extract Entitlements.application-identifier raw -

# The team the binary was signed by
codesign -dv --verbose=4 /path/to/Shop.app 2>&1 | grep TeamIdentifier

Team ID vs App ID Prefix

Apple unified the two in 2013: App IDs created since then use the Team ID as their prefix. App IDs created before that, or migrated between accounts during a company acquisition or an account merge, kept their original prefix. Those App IDs still work, still build, still ship — and their AASA entry is not the value on your Membership page.

How it is used in the AASA file

The appIDs array holds fully qualified App IDs: the prefix, a dot, then the bundle identifier. Several apps can share one entry, which is how a main app, an enterprise build and an App Clip live in the same file.

{
  "applinks": {
    "details": [
      {
        "appIDs": [
          "A1B2C3D4E5.com.example.shop",
          "A1B2C3D4E5.com.example.shop.enterprise",
          "9Z8Y7X6W5V.com.example.shop.legacy"
        ],
        "components": [
          { "/": "/products/*", "comment": "Product pages" }
        ]
      }
    ]
  },
  "appclips": {
    "apps": ["A1B2C3D4E5.com.example.shop.Clip"]
  }
}

The third entry uses a different prefix on purpose: an App ID inherited from an acquired account. Both are correct at the same time, and this is exactly the case that breaks when someone "tidies up" the file by making all the prefixes match.

• The prefix is case-sensitive and always uppercase.
• There is no separator other than a single dot between prefix and bundle ID.
• A wildcard App ID such as A1B2C3D4E5.com.example.* cannot be used here — Associated Domains requires an explicit App ID.
• The same prefix is what appears in webcredentials and appclips, which is why one wrong prefix breaks password AutoFill and App Clips along with Universal Links.

Verifying before you deploy

Two checks, one on each side, catch every prefix mismatch before it reaches a user.

# 1. What the app claims to be
codesign -d --entitlements :- Shop.app 2>/dev/null | \
  grep -A1 application-identifier

# 2. What the domain authorises, as Apple's CDN serves it
curl -sS https://app-site-association.cdn-apple.com/a/v1/example.com | \
  python3 -m json.tool | grep -i appid

The string from the first command must appear verbatim in the output of the second. If it does not, nothing else about the setup matters yet. If it does and links still fall through, the problem has moved on to path matching or hosting — see universal-links-not-opening-app.