Deep Links and Universal Links Explained
By CodexierPublished 5 min read
When someone taps a link to your product in an email, a text message or an ad, they expect to land on the right screen, in the app if they have it installed. Getting there is less obvious than it sounds. Links pass through click trackers, in-app browsers and operating system rules, and each can send the user to your website instead. This guide explains how deep links work, why they break and what to test.
What a deep link does
Early deep links used custom URL schemes such as myapp://booking/123. They still work but have drawbacks: they fail with an error if the app is not installed, and any app can claim the same scheme. Modern apps use verified https links instead. The same link works everywhere, opens the app when possible and shows the matching web page otherwise.
Universal Links and App Links
| Aspect | iOS Universal Links | Android App Links |
|---|---|---|
| Verification file | apple-app-site-association in /.well-known/ on your domain | assetlinks.json in /.well-known/ on your domain |
| Proves | That your domain trusts your app's team and bundle ID | That your domain trusts your app's package and signing certificate |
| App configuration | Associated Domains entitlement listing the domain | Intent filters with autoVerify for the domain and paths |
| Without the app | Opens the URL in Safari | Opens the URL in the browser |
The files must be served over HTTPS without redirects, with the correct content type. A website redesign or hosting move that drops them breaks every link silently.
Why links fall back to the browser
- Click tracking: email and SMS tools rewrite links to their own tracking domain, which is not associated with your app.
- In-app browsers: links tapped inside Instagram, Facebook or LinkedIn often open in their built-in browser rather than your app.
- Missing or broken verification files after a website change.
- Paths not covered by the app's configuration.
- iOS remembers if the user chose to open a domain in Safari, and keeps doing so.
- The app is installed but the screen for that path is not implemented, so it opens the start screen.
Deferred deep linking handles the case where the app is not installed: the user goes to the store, installs, and on first launch lands on the intended screen. This needs a third-party attribution service or your own server-side matching. Firebase Dynamic Links used to cover it, but Google shut that service down in 2025, so apps relying on it need a replacement.
Links in email and campaigns
Marketing and product teams should agree on link rules before a campaign goes out. The most common failure is a well-built app link that never reaches the app because the newsletter tool wrapped it in tracking. Many email providers can serve click tracking from your own subdomain, and that subdomain can be associated with the app.
Branded tracking domain
Set up click tracking on a subdomain you own and include it in the app's associated domains.
Matching web pages
Every deep link path should also exist on the website, so users without the app see something useful.
Campaign parameters
UTM parameters can be kept on the link; make sure the app reads and reports them to analytics.
Testing and maintaining them
- Keep a list of every link pattern the app supports and the screen it should open.
- Test each on a real iPhone and Android device, with and without the app installed.
- Test from Mail, Gmail, SMS, Notes and at least one social app.
- Check the verification files after every website deploy; automate it if you can.
- Include deep link tests in the release checklist for each app update.
Deep links touch the website, the app and marketing tools at once, which is why they break quietly. We check them as part of app maintenance. When you do not need it: if your app is used only after login and never linked from outside, simple in-app navigation may be enough. If your campaigns keep landing users in the browser, book a free call.
Frequently asked questions
Why does my link open the website even though the app is installed?
Most often the link was rewritten by a click tracker, tapped inside an in-app browser, or the verification file on your domain is missing or wrong. On iOS, the user may also have chosen to open the domain in Safari earlier.
Do we still need a custom URL scheme?
Rarely for links from outside. Verified https links are better for users and security. A custom scheme can still be useful for app-to-app callbacks, for example from payment or login flows.
What replaced Firebase Dynamic Links?
Google recommends using Universal Links and App Links directly, combined with an attribution or deep linking provider if you need deferred deep links and campaign tracking.
Can deep links be a security risk?
Yes, if the app trusts parameters in the link blindly. Validate every parameter, require login for sensitive screens and never perform actions just because a link was opened.
Links not opening your app?
Send us a link that fails. In fifteen minutes we can usually tell you where it breaks and what the fix involves.
Book a free 15-minute call