Validate your Universal Links and App Links setup.

Fetch your apple-app-site-association from https://yourdomain.com/.well-known/apple-app-site-association and confirm three things: it returns a single 200 with no redirects, the Content-Type is application/json, and the appIDs are in prefix.bundle.id form. The validator above checks all three at once, along with the Android equivalent.

No. It only uses the link's domain. It fetches that domain's apple-app-site-association and assetlinks.json and checks them; it doesn't open your link or follow where it leads, so it can't tell you how one particular link routes. If both files pass, links on that domain can open your app for people who already have it installed.

Almost always because the AASA never validated, and iOS reports no error when it doesn't. In order of likelihood: the file is served as text/plain or text/html rather than application/json, a redirect sits in front of it, the Associated Domains entitlement is missing from the build you installed, or the user previously tapped the breadcrumb back to Safari — iOS remembers that choice per domain.

Apple's documentation specifies application/json, and that's what you should serve. In practice iOS parses the file whatever the header says, which is why plenty of sites serving it as application/octet-stream still have working Universal Links — the validator above flags that as a warning, not a failure. Fix it anyway for two reasons: only the documented contract is guaranteed to keep working across iOS releases, and a wrong Content-Type usually means the file is being served by accident rather than on purpose. The header that genuinely breaks things is text/html, which almost always means your server answered with a 404 or single-page-app fallback at a 200 status.

Usually a signing fingerprint that isn't listed in assetlinks.json — most often Google's Play App Signing key, which you never see locally. Run adb shell pm get-app-links your.package.name on a device: if it doesn't say verified, the problem is your association file or Google's crawl of it, and no amount of app code will fix it.

Longer than you'd like, because there are two caches between your fix and a working link. iOS retrieves the AASA through an Apple-operated CDN, so a delete-and-reinstall is usually the fastest reliable check. On Android, Google re-crawls assetlinks.json on its own schedule and the device stamps its verdict at install — force a re-check with adb shell pm verify-app-links --re-verify.

No. The check runs against the two publicly available association files on the domain you enter, and nothing is stored or required — no signup, no account, no email.

You need them, but you don't maintain them. LinkTrail generates and serves both files from your link domain with the correct Content-Type and no redirects, and regenerates them when you add a bundle ID or a signing fingerprint.