The right Firebase Dynamic Links alternative depends on which part of Dynamic Links you actually used. If your links only sent iPhone users to the App Store and Android users to Google Play, a no-SDK store link replaces them in a few minutes; if your app relied on deferred deep linking or install attribution, you need an SDK platform such as Branch, AppsFlyer or Airbridge.
Most migration guides skip that question, mainly because most of them are written by companies that sell the SDK. Google switched Dynamic Links off on August 25, 2025, and since then every page.link URL returns a 404. That includes the ones on posters, in onboarding emails and in old App Store descriptions. This guide splits Dynamic Links into the four jobs it did, shows what replaces each one, and covers the links you already handed out.
What happened to Firebase Dynamic Links
Firebase Dynamic Links shut down on August 25, 2025. According to the Firebase FAQ, every clicked link now returns an HTTP 404 to the end user, and page.link subdomains are no longer available. The Short Links and Analytics APIs went with it.
Google's own guidance offers three paths: move to a third-party deep linking provider (it names Adjust, Airbridge, AppsFlyer, Bitly, Branch, Kochava and Singular, and says it has not vetted them), use Android App Links and iOS Universal Links if you only need post-install linking, or replace nothing and remove the SDK. The same date also retired inactive goo.gl links, which is covered in the post on the Google URL Shortener alternative.
There is no switch to flip that brings the old links back.
Which part of Dynamic Links did you actually use?
Dynamic Links bundled four different jobs behind one URL. Very few apps used all four, and each one has a different replacement with a very different price tag.
| Job Dynamic Links did | How you can tell you used it | What replaces it |
|---|---|---|
| Store routing | The link sent iPhones to the App Store and Android phones to Google Play | A no-SDK store link |
| Opening the app if installed | Tapping the link opened your app instead of a browser | Universal Links (iOS) and App Links (Android) on your own website |
| Deferred deep linking | A new user installed the app and the first launch opened specific content, like an invite or a product | An SDK platform: Branch, AppsFlyer, Airbridge |
| Install attribution | You checked first opens per link in the Firebase console | An attribution (MMP) SDK |
Here's the quick test. Search your app code for the Dynamic Links SDK calls: getDynamicLink on Android, handleUniversalLink on iOS, getInitialLink or onLink in Flutter. If nothing reads the incoming link, your app never used rows two to four. The links were doing store routing, and that is the cheapest row to replace.
If the search does find handlers, look at what they do with the link. Code that only logs the URL is a different case from code that opens a referral screen.
If you only need store routing: a no-SDK link
Store routing doesn't need anything inside your app. A link checks the visitor's device and forwards it: iOS to the App Store, Android to Google Play, everything else to a web page you choose. The mechanics are in the post on one link for the App Store and Google Play, so here is only the setup.
With an app download link in Linxly, it goes like this:
- Create a deep link and paste your App Store and Google Play URLs.
- Set a fallback for desktop, usually your website.
- Pick the ending, for example
linx.ly/your-app, and save. The QR code is generated at the same time.
One detail people miss: when someone who already has the app opens the link, the store listing shows Open instead of Get or Install. So the link does not launch the app on its own, but existing users are still one tap away from it.
The Starter plan ($0.99 a month) includes 2 deep links for iOS and Android. Huawei AppGallery routing starts on Pro ($7.99 a month), which also raises the count to 20 deep links.
If you need deferred deep linking or attribution
Deferred deep linking means context survives the install: someone taps an invite link, installs the app, and the first launch opens that invite. Carrying context through the store requires code inside your app that asks a server "what link brought this user here?" Attribution works the same way. Neither is possible with a plain redirect, and Linxly doesn't do either. If your referral program or onboarding depends on them, this is where your budget goes.
The main options, with prices from their own pricing pages:
- Branch doesn't publish prices. Its pricing page lists Basics, Essentials and Enterprise plans, with a trial on Basics and demo requests for the rest.
- AppsFlyer has a Zero plan meant for owned media, with 12,000 free conversions in the first year, and charges $0.07 per conversion after that on its Growth plan (AppsFlyer pricing).
- Airbridge Core starts at $40 a month after a 30-day trial and includes deferred deep links (Airbridge pricing).
Before you sign anything, ask one honest question. If a new user lands on the home screen instead of the invite, does anything break? If they can still find the invite in two taps, you may be paying for an SDK to save those two taps.
Opening the app when it's installed
If you want a tapped link to open your app directly, you don't need a vendor. Apple and Google both support this natively, and Firebase points to these as the replacement for post-install linking.
On iOS that means Universal Links: an apple-app-site-association file at /.well-known/ on your website, plus the Associated Domains entitlement in the app. On Android it's App Links: an assetlinks.json file at /.well-known/assetlinks.json and an intent filter with android:autoVerify="true". Plan for a developer afternoon and an app release. After that there is nothing to renew.
The catch is the user without the app. A Universal Link then just opens your web page in the browser, so that page should carry store buttons or your store link.
To be clear, Linxly does not open the app. It sends people to the store listing. The two fit together fine: your own Universal Links for existing users (emails, in-app shares), a store link for everyone you are still trying to win (ads, bio, print).
Replacing links you already shared
Nobody can redirect an old page.link URL. The subdomain belonged to Google, it is gone, and no tool, Linxly included, can take over its traffic. The only fix is to replace the link wherever it was published, so start with an inventory.
Sort it by how hard each place is to change. Printed QR codes on packaging, posters and business cards come first, because they keep sending people to a 404 for as long as they exist. Next come automated templates: welcome emails, receipts, push notifications. Then the slow-moving pages, such as App Store and Google Play descriptions, your website's download buttons and help center articles. Social posts can wait. Most of the traffic from a two-year-old post is already gone anyway.
Whatever you print or send next, make it a link whose destination you can edit later. Dynamic Links went on the same day Google retired inactive goo.gl links. If the link on the box is yours, a store URL change or a provider shutdown means editing one field instead of reprinting. In Linxly, destination editing is on every plan, and the app download QR code post covers the print side.
Check your app's share code first. If the app builds invite or share links in code, it may still be generating page.link URLs today, and that is the one item on your list that keeps growing until you ship an update.
Firebase Dynamic Links alternatives compared
| Linxly | OneLink.to | Branch | Build it yourself | |
|---|---|---|---|---|
| Store routing without an SDK | Yes | Yes | Yes, through its platform | Yes, you write the redirect |
| Opens the app if installed | No, sends to the store listing | Lists "Open in App" | Yes | Yes, with Universal Links and App Links |
| Deferred deep linking | No | Lists it for Android | Yes | No |
| Install attribution | No, click analytics only | Not listed | Yes | No |
| Starting price | $0.99/month, 7-day free trial | Paid plans from $10/month | Not published | Hosting plus developer time |
OneLink.to and Linxly both route by device without an SDK. The difference is what comes with the link. Linxly includes a URL shortener and a bio link page in the same account, every link gets a QR code automatically, and you can change the store destinations after the link is out. Plans start at $0.99 a month, about a tenth of OneLink.to's lowest paid plan. On Starter you see clicks, country and device type. OS, referrer and city start on Pro. The OneLink.to alternative post compares the two in detail.
Building it yourself is cheaper than it looks for store routing and more expensive than it looks for everything else.
Frequently Asked Questions
Is Firebase Dynamic Links still working?
No. Firebase Dynamic Links shut down on August 25, 2025, and every link now returns an HTTP 404 to the person who opens it. The page.link subdomains are no longer available.
Can I move my old page.link links?
No. The page.link subdomains belonged to Google, so no provider can take over their traffic. Replace the links where they were published, and use links you can edit later this time.
Is there a Firebase Dynamic Links alternative without an SDK?
Yes, for store routing. A device-based store link sends iOS users to the App Store and Android users to Google Play with nothing installed in your app. Opening the app directly needs Universal Links and App Links, which you set up in your app yourself.
Does Linxly do deferred deep linking?
No. Linxly routes each visitor to the right store and records the click, but it does not carry context through the install or attribute installs. For that you need an SDK platform such as Branch, AppsFlyer or Airbridge.
How much does it cost?
Linxly starts at $0.99 a month, with 2 deep links for iOS and Android on Starter. Every plan begins with a 7-day free trial, and you can cancel anytime.