Managing link verification across multiple apps and bundle IDs

A single app with one bundle ID and one signing key is the easy case for Universal Links and App Links. Real products outgrow that fast: a white-label build, a staging app, a debug variant, an acquisition that adds a second package. Every one of those needs to appear in your association files, correctly, or links silently stop opening the app.

When one appID isn't enough

The moment you ship more than one build that should open the same links, your AASA needs multiple appIDs and your assetlinks.json needs multiple targets. Miss one and that build falls back to the browser with no error — the worst kind of failure, because it looks fine in QA on the build you remembered to add.

{
  "applinks": {
    "details": [
      {
        "appIDs": [
          "TEAMID.com.example.app",
          "TEAMID.com.example.app.staging"
        ],
        "components": [{ "/": "/l/*" }]
      }
    ]
  }
}

Android is the same story: one object per package, and crucially one fingerprint per signing key — debug and release are different keys, so both belong in the list while you're still sideloading test builds.

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.app",
      "sha256_cert_fingerprints": ["AA:BB:...debug", "CC:DD:...release"]
    }
  }
]

Regenerate, don't hand-edit

The failure mode is always a stale, hand-maintained file. Treat the association files as generated artifacts keyed off your registered bundle IDs and signing certs, so adding a build target updates them automatically. A managed link domain does this for you and serves both files with the correct content type and no redirects.

Verify it's actually live

Trust nothing until you've checked the wire — our free Universal Links validator fetches both association files for any domain and flags the classic mistakes. The two failures that bite hardest are a wrong Content-Type on the extension-less AASA and a redirect in front of it — Apple's fetch follows neither.

curl -sI https://yourapp.linktrail.io/.well-known/apple-app-site-association | grep -i content-type
# Expect: content-type: application/json

adb shell pm verify-app-links --re-verify com.example.app