Mobile links and app association
A link is an API entry. Read the association files, then open a link for your own account and record which app and which request result.
Tags: mobile, deeplink, applink, oauth
Checklist
- Association files: assetlinks.json and apple-app-site-association. Package name, team id, paths, and whether the file is HTTPS with the content type the platform expects.
- Claimed paths: Hosts and paths the app claims, compared with the web routes that exist. A claimed path with no server route is still worth noting.
- Verification failures: A sibling host that opens the app, or a claimed host whose association file fails to verify. Write the host and the file status.
- Link parameters: Tokens, next URLs, and object ids in the link. The app should not treat a parameter as proof that the opener is allowed.
- Web fallback: If the app is not installed, the browser route should not put a one-time token in a third-party referrer or send the browser to a host you did not intend.
- Which account opens: Same link logged out, logged in as A, and logged in as B. Record which account the object opens under.
- Custom schemes: Note the scheme and that other apps may be able to register it. Prefer the verified HTTPS link when you judge impact.
- One-time links: OAuth redirect URIs and magic links opened in the app or a web view. Single use, user binding, and whether the web view shares the app cookie jar.