The plain case
A deep link is a URL that names a destination inside an app rather than a page on the web — a product, an invite, a chat thread, a password reset. When the app is installed, the operating system hands the link to the app, and it opens that screen instead of the browser opening a page.
Two mechanisms do this, and they are not interchangeable.
Custom URL schemes — myapp://product/42 — are the older form. Any app can claim any scheme and nothing verifies the claim, so two apps can fight over the same one. Worse, the URL means nothing outside the device: tapped without the app installed it goes nowhere, and it cannot be posted anywhere a browser might open it. Schemes still have a place in app-to-app handoffs on the same device; they are a poor basis for links you send to people.
Universal Links on iOS and App Links on Android are ordinary https:// URLs that your app claims by serving a signed association file from your own domain — apple-app-site-association and assetlinks.json respectively. The platform fetches that file and verifies the claim, so nobody can hijack your links, and the same URL still works as a web page for anyone without the app. This is the form to build on.
Three things people call a "deep link"
| What it does | Without the app installed | |
|---|---|---|
| Custom scheme | Opens a screen via a private myapp:// URL | Nothing happens — the link is a dead end |
| Universal / App Link | Opens a screen via a verified https:// URL | Falls back to your web page |
| Deferred deep link | Opens a screen after the app is installed | Sends the user to the store, then restores the destination on first launch |
Most arguments about deep linking are really people using one of these three words and hearing another. The first two are configuration. The third is a genuine engineering problem.
The hard case: surviving an install
Everything above assumes the app is already there. When it is not, the tap sends the user to the App Store or Google Play, and the app that eventually launches is a fresh install with no memory of what was tapped. They land on a generic home screen, and whatever they wanted is gone.
Deferred deep linking is the part that carries the destination across that gap, and it is hard for a specific reason: between the tap and the first launch there is no shared state. A newly installed app has never seen the browser session that started the journey, so something has to smuggle a payload across an OS boundary that was deliberately built to stop exactly that.
The mechanisms are platform-specific. On iOS an App Clips can capture the link before the full app exists and hand it over through a shared container. On Android the Install Referrer API delivers the campaign parameters deterministically on first launch. Firebase Dynamic Links used to hide both behind a single SDK, and it shut down in August 2025 — which is why this is a live question again rather than a settled one.
The two shortcuts that look easier are worth naming so you can refuse them. Device fingerprinting matches a browser and an app by IP address, screen size and locale within a short window; it degrades badly on shared and carrier networks, and probabilistic matching of users is precisely the pattern platform privacy rules push against. Clipboard matching copies the payload and reads it back on launch; since iOS 14 it shows the user a paste banner, and any other copy in between destroys it. Both are guesses dressed as infrastructure.
Where it breaks in practice
- The association file. A redirect, a wrong content type, or a stale cache and the platform quietly stops honouring your claim. The symptom is not an error — it is your links opening the website instead of the app, which is easy to miss in testing and expensive in production.
- In-app browsers. Links tapped inside social apps often open in an embedded webview that never hands off to the OS, so a universal link that works from Messages does nothing from a feed.
- No web fallback. If the
https://URL has no real page behind it, everyone without the app gets a 404 — the exact audience you were trying to convert. - Attribution. Without a referrer surviving the install, you cannot tell which campaign produced which user, and the acquisition numbers you report are estimates.
When it is worth the trouble
A link that drops someone on a generic home screen has spent the one moment of intent you were given. Shared content, invitations, password resets and every paid acquisition campaign depend on the destination surviving the trip — and so does knowing what you paid per install.
It is not always worth it. An app whose entire value is behind a login that everyone reaches anyway, or a product with no sharing and no paid acquisition, can ship without deferred handling and lose nothing. The cost is real: an App Clips target is a second binary to build, sign and keep under 15 MB.
We wrote up the full implementation — both platforms, and the pending-link queue that waits for login before it routes — in deferred deep linking after Firebase Dynamic Links.