Replacing Firebase Dynamic Links
The shutdown forced a lot of teams to find out which parts of their link setup were doing real work and which were habit.
6 August 2026 by PAD team
What it did
Dynamic Links bundled several jobs into one URL: open the app if installed, otherwise send to the store, remember the destination across the install, and provide a preview page for social sharing. Only some of those need a specialised product.
What a plain link can do
| Job | Replaceable with |
|---|---|
| Open the app if installed | universal links and App Links |
| Send to the store otherwise | a store URL with routing |
| Carry campaign parameters | ct on iOS, referrer on Play |
| Survive in-app browsers | an escape sequence in the landing page |
| Remember the destination after install | an attribution SDK, no way around it |
That last row is the only genuinely hard one. Matching an install to the click that caused it requires something running inside the app at first launch.
Choosing by what you actually used
If Dynamic Links was mostly sending people to the store from social posts, you do not need an SDK to replace it. If your product relies on landing users on a specific screen after installing, you need AppsFlyer, Branch or Adjust, and the migration is bigger than swapping a URL.
The part everyone forgets
Whatever you migrate to, the last hop is still a store URL, and inside Instagram or Facebook that URL fails the same way it always did. Attribution products measure the tap without rescuing it, which is covered in detail here.
For the store-facing half, one link that routes correctly and survives in-app browsers.