ReferenceIntermediate4-6 min reference
Deep Links & Universal Links
A link that opens a specific screen in an app instead of a web page — until it doesn't, because the app is killed, not installed, or the user isn't logged in. The terminology differs by platform and trips people up. This sheet is the lookup and the test matrix; see Mobile Testing for the wider context.
The link types
| Type | Platform | Note |
|---|---|---|
Custom URL scheme (myapp://) | Both | Oldest; can be hijacked by another app, no web fallback |
Universal Links (https://…) | iOS | Verified via apple-app-site-association file |
App Links (https://…) | Android | Verified via assetlinks.json (Digital Asset Links) |
| Deferred deep link | Both | Survives install: link → store → first launch routes to target |
Verified https links (Universal/App Links) are preferred — they fall back to the web if the app isn't installed.
The state matrix (where bugs hide)
| State | Expected |
|---|---|
| App installed + running | Opens the target screen directly |
| App installed, killed | Cold-starts to the target screen with context |
| App not installed | Falls back to web (or store, then deferred routing) |
| Logged out | Routes to login, then continues to the target |
| Invalid / expired link | Graceful error, sensible default screen |
What to test
- Each state above for your key links.
- Routing preserves parameters (ids, promo codes, UTM).
- The verification files are reachable and valid (
apple-app-site-association,assetlinks.json). - Web fallback works when the app is absent.
- Login interception then resumes to the original target.
Common mistakes
- Testing only the app-running state.
- Custom scheme with no web fallback (dead link if app missing).
- Losing link parameters through the login redirect.
- Broken/unreachable association files, silently disabling verified links.
- No graceful handling of malformed or expired links.
// Related resources