What Is a Deep Link? A Plain-English Guide

A deep link is a URL that opens a specific screen inside a mobile app instead of the app's home screen or a plain website. Tap a normal link to a shop and you get the homepage; tap a deep link and you land on the exact product. That difference, landing in the right place rather than the front door, is the whole point, and it is what makes app campaigns actually convert.

This is the plain-English version: what a deep link is, the types you will hear named (universal links, app links, deferred deep links), and what changed now that Firebase Dynamic Links has shut down. For the hands-on setup, deep links without an SDK covers the implementation; this post covers the concepts first.

What a Deep Link Actually Is

Start with the contrast. A normal web link points at a page. On a phone, if you have the relevant app installed, tapping it often just opens the app's home screen, and you have to navigate to what you wanted. A deep link skips that: it carries the address of a specific in-app destination and opens it directly.

The mechanism underneath is a regular HTTPS URL that the operating system recognises as belonging to an app. When the OS sees it, it hands the link to the app and the app opens the matching screen. If the app is not installed, the same URL falls back to the web version, so the user always gets somewhere. That fallback is the feature that makes the modern versions reliable.

The Types You Will Hear Named

"Deep link" is the umbrella term. Underneath it sit a few specific technologies, and the names get used loosely, so here is the map.

• Universal links (iOS) and app links (Android) are the OS-level, HTTPS-based way to open app content, with automatic web fallback when the app is missing. These are the modern default; Apple documents the iOS side under universal links.
• Custom URI schemes (myapp://product/123) are the old way. They work, but if the app is not installed the link fails with nothing to fall back to, so they are no longer recommended on their own.
• Deferred deep links carry the destination through an app install, so a new user who taps a link, installs the app, and opens it lands on the intended screen rather than a blank home page.

Universal links and app links are what Apple and Google recommend, and for good reason: they are HTTPS, they fall back gracefully, and they do not need an SDK for the basic case.

Life After Firebase Dynamic Links

If you built anything on deep links in the last few years, this is the part that changed.

Google shut down Firebase Dynamic Links on 25 August 2025. Existing links stopped working and now return an error, and no new ones can be created. The catch is that Firebase Dynamic Links did more than open app screens: it was a dynamic deep-link service that added deferred deep linking and platform-aware routing on top of the native mechanisms. Teams that used it for the plain case can migrate to universal and app links directly. Teams that relied on the deferred and routing features need to replace those too, which we walk through in migrating from Firebase Dynamic Links.

The shutdown is a good moment to separate what you actually use. If you only ever opened a known screen, native links cover you. If you depended on install-time routing, you need a service that does deferred deep linking. Do not rebuild features you were not using.

If you want the routing and analytics layer without stitching it together yourself, Elido's deep links sit on top of your short links, and you can set one up on the free plan. For messaging-driven flows specifically, WhatsApp Business deep links and Telegram deep links are worked examples.

When You Need Deferred Deep Linking

The plain deep link handles the easy case, where the app is already installed. Deferred deep linking handles the hard one, where it is not, and it is worth understanding because it is where campaigns leak users.

Picture an ad for a specific product. A user without the app taps it, gets sent to the app store, installs, and opens the app, and by default they land on a generic home screen, because the original destination was lost somewhere between the tap and the install. A deferred deep link stores that intent and delivers the user to the exact product screen on first open. The gap between "installed the app" and "found the thing they wanted" is where conversions die, and deferred deep linking closes it.

So the short version: use universal and app links for the everyday case, add deferred deep linking when you run install campaigns, and reach for a service when you need routing and attribution on top. The concept is simple; the value is in landing people in the right place every time.

Do You Need an SDK?

For the everyday case, no. Universal links and app links are set up with a small association file hosted on your domain plus some app configuration, and no SDK is involved. You reach for a service or SDK the moment you want the harder features: deferred deep linking that survives an install, routing that picks a destination by platform, or attribution that ties an install back to the campaign that drove it. Those need server-side logic a static native link cannot provide. Match the tooling to whether you need install-time behaviour, and do not pull in an SDK for links that only ever open a known screen.

Related on the Blog

• Deep links for mobile apps without an SDK
• Migrating from Firebase Dynamic Links: the replacement stack
• Smart links explained: routing by country, device, language
• WhatsApp Business deep links, done right
• Telegram deep links: track t.me and bot start links