Same problem, two implementations. A URL opens your app directly instead of bouncing through a browser, with no "Open in app?" prompt.
The mechanics
Android App Links — you host /.well-known/assetlinks.json on your domain, listing your package name and signing certificate fingerprint. Android verifies it at install and routes matching URLs to your app.
iOS Universal Links — you host /.well-known/apple-app-site-association and add the Associated Domains entitlement. iOS fetches the file and maps paths to your app.
Both require HTTPS on a domain you control. Neither works on a shared domain, which is why generic URL shorteners cannot give you verified links.
What they do not do
Verified links cover the installed case. That is re-engagement: email, push fallbacks, someone returning to content.
They do nothing for a user without the app. The link opens the browser and whatever destination it carried is lost. Carrying context through an install is deferred deep linking, which is a separate layer on top.
Teams routinely discover this after shipping, when new-user links all land on the home screen.
Why verification fails
The file is unreachable. It must be served over HTTPS with no redirects, at the exact .well-known path.
Wrong content type. The association file should be served as application/json. Some hosts add an extension or serve it as plain text.
Fingerprint mismatch on Android. The certificate fingerprint in assetlinks.json has to match the one that signed the build. Play App Signing changes this, and it is the single most common Android failure.
Caching on iOS. The association is fetched at install. Publish the file after users install and their devices will not pick it up until reinstall.
The practical order
Get one platform verified end to end before starting the other. Test on a real device, not a simulator. Then confirm the web fallback still works correctly for anyone who does not have the app — because that is most people.
Frequently asked questions
- What is the difference between App Links and Universal Links?
- They are the same idea on different platforms. Android App Links verify ownership through an assetlinks.json file; iOS Universal Links verify through an apple-app-site-association file. Both need an HTTPS domain you control, and a cross-platform app needs both configured.
- Do I need both?
- Yes, if you ship on both platforms. They are not interchangeable. Android will not read an apple-app-site-association file and iOS will not read assetlinks.json.
- Why is my Universal Link opening Safari instead of the app?
- Usually the association file is unreachable, served with the wrong content type, or the app was installed before the file was published. iOS caches the association at install time, so publishing the file afterwards does not retroactively fix installed devices.
- Do verified links work when the app is not installed?
- No. Verification proves your app owns the domain so the link opens without a prompt. With no app installed there is nothing to open, so the URL loads in the browser as an ordinary web address.
Read more
Fundamentals · 1 min read
Bitly vs Dub vs Bridgly: picking by job
Bitly shortens. Dub pays digital partners. Bridgly routes app installs and ties physical QR scans to attributed sales and commissions.
Fundamentals · 2 min read
Deferred deep linking, explained without the jargon
Deferred deep linking carries a destination across an app install, so a new user lands where they were headed instead of your home screen. Here is how the matching works, why it is never perfect, and when it is worth the setup.
Fundamentals · 4 min read
What is a universal install link (and why two store links lose installs)
A universal install link is one URL that detects the visitor's device and routes to the App Store, Google Play, or web. Here's how the routing works, why posting two store links costs installs, and what to check before you ship one.