Free tool
AASA validator
Check a domain's apple-app-site-association file the way Apple reads it, and compare it with the copy on Apple's CDN, which is the one iOS actually installs.
What this checks
- The file is at
/.well-known/apple-app-site-association, over HTTPS, with a 200 and no redirects. Apple doesn't follow them, and a redirect towwwis the most common reason Universal Links silently fail. - It's valid JSON, under Apple's 128 KB limit.
applinks.detailslists your app asTEAMID.bundle.id, withpathsorcomponentsthat match your URLs.- Apple's CDN copy matches yours. If it doesn't, devices still have the old rules.
Questions
- Why do my Universal Links still open Safari after I fixed the file?
- iOS doesn't read your server directly. It installs the copy on Apple's CDN, which refreshes on its own schedule, often a day or more later. During development, add ?mode=developer to the associated domain in your entitlements so a development build fetches your server instead.
- Does the file need a .json extension?
- No. It lives at /.well-known/apple-app-site-association with no extension, served over HTTPS with a 200 and no redirects. application/json is the right Content-Type.
- What's the difference between paths and components?
- paths is the original format: a list of path patterns. components (iOS 13 and later) matches the path, query and fragment separately and can exclude patterns. Both still work; components is easier to get right.
- Do I have to write and host this file myself?
- Not with DeepLinkNow: it generates and serves apple-app-site-association and assetlinks.json for your link domain from your app settings, so there's nothing to upload or keep in sync.
Never hand-edit this file again
DeepLinkNow serves apple-app-site-association and assetlinks.json for your link domain, and any path on it works as a deep link, even across an install.