How a Dynamic Link Works
A dynamic link is one URL that behaves differently for every person who taps it. The link service looks at the request, works out the device platform, checks whether the app is likely installed, and then chooses the destination. The same link can open a product screen inside the app on an iPhone, send an Android user to Google Play, and show a web page on a laptop.
Behind the link sits a set of rules. Each link stores a deep link value (the in-app destination), store URLs for iOS and Android, a web fallback, and any campaign parameters. When the app is installed, the link hands off to Universal Links on iOS or App Links on Android so the operating system opens the app directly. When the app is missing, the service redirects to the store and remembers the destination, so the app can retrieve it on first open. That second step is deferred deep linking, and it is what makes dynamic links useful for acquisition.
Because the routing happens on the server, you can change where a link goes after it has been printed on a poster or shared in a chat. The URL stays the same while the destination behind it moves.
The End of Firebase Dynamic Links
For years "dynamic links" meant one product: Firebase Dynamic Links (FDL). Google announced its deprecation in 2023 and shut the service down on 25 August 2025. After that date FDL links stopped resolving, including links on custom domains configured through Firebase, and the SDK methods that read incoming links stopped returning data.
The shutdown pushed many teams to move millions of links at once. Stratzy, for example, migrated 1.23 million Firebase Dynamic Links when it moved its link setup to Linkrunner. The lesson for everyone else is that a link is a long-lived asset. Links sit in old emails, printed packaging, influencer bios and referral messages for years, so the provider behind them needs to be one you expect to keep running, and ideally one that serves links from a domain you own.
If you still have FDL links in circulation, they no longer route. The Firebase Dynamic Links migration guide covers how to rebuild them with equivalent behavior.
Dynamic Links vs Other Link Types
The deep linking vocabulary overlaps, so it helps to separate the terms. A custom URL scheme like myapp://product/42 opens the app only when it is installed and fails otherwise. Universal Links and App Links are verified HTTPS links that open the app when installed and the website when not. Neither of these carries a destination through an install on its own.
A dynamic link sits on top of these building blocks. It uses Universal Links and App Links for installed users, store redirects for new users, and a stored payload for deferred deep linking. Smart links and branded links describe the same idea from different angles: a smart link emphasises routing, a branded link emphasises that the link runs on your own domain.
An attribution link adds measurement. Every tap becomes a click record with source, campaign and creative, so the install and later events can be credited to the right campaign.
What to Look For in a Dynamic Link Provider
The basics are table stakes: correct routing on iOS and Android, deferred deep linking that survives the install, and a desktop fallback. Beyond those, a few details separate a provider you can rely on from one that causes support tickets.
Domain ownership matters most. Links on your own domain or branded subdomain keep working if you ever change provider, because you control where the domain points. The provider should host the apple-app-site-association and assetlinks.json files for that domain so verification stays correct as your app changes.
In-app browsers are the second detail. Links opened inside Instagram, Facebook or TikTok often load in a webview that blocks Universal Links. A provider should detect this and offer a way out, such as an intermediate page that opens the app or the store. Linkrunner's deep linking handles this with a social intermediary page, along with branded subdomains, redirection rules and a QR code for every link.
Finally, check measurement. If the same link that routes users also attributes installs, you avoid stitching data from two tools together.
Common Dynamic Link Mistakes
The most common failure is treating the link as the whole integration. The app still has to read the incoming link, both on a normal open and on first launch after install, and route the user once its navigation is ready. Apps that only check for a link at cold start miss links that arrive while the app is already running.
Another mistake is losing the destination at login. If the target screen needs an account, queue the destination, let the user sign in or sign up, then route. Dropping the link at the auth wall is a frequent cause of low deep link completion rates.
Teams also forget to test the long tail: links opened from email clients that rewrite URLs, from in-app browsers, from QR scanners and from desktop. Build a short test matrix covering installed and not installed states on both platforms, and run it whenever you change link domains or app versions.