Firebase Dynamic Links was a convenient service while it lasted. You could generate short links, handle deferred deep linking, and route users across install states without much infrastructure. Then Google announced the deprecation in 2024, with the service shutting down in August 2025.
If you still have Firebase Dynamic Links in your app, those links are now broken. If you are evaluating your options, this article compares what you had with Firebase against native Android App Links, covers what requires a third-party platform to replace, and helps you make an informed decision.
What Firebase Dynamic Links Actually Did
Before comparing, it helps to be precise about what Firebase Dynamic Links provided, because "dynamic links" covered several distinct capabilities bundled together:
Short link generation. Firebase gave you a URL shortener that produced yourdomain.page.link/xyz or custom domain short links.
Deferred deep linking. If a user clicked a link before installing your app, Firebase stored the destination and reopened it after install. This was the hardest part to replace, because Android has no native equivalent.
Cross-platform routing. The same link could route iOS users to the App Store, Android users to the Play Store or your app, and desktop users to a web fallback.
Basic analytics. Firebase tracked clicks and installs attributed to Dynamic Links.
Android App Links, by contrast, is a single piece of this puzzle: a system that lets your app intercept HTTPS URLs without a browser chooser dialog. App Links handles the "user has the app installed and clicks a link" case. It does nothing for the deferred install case.
This distinction matters for migration planning.
How Android App Links Work
Android App Links work through a verification system. Your app declares intent filters for your domain, and Android verifies that your domain hosts an Asset Links JSON file at /.well-known/assetlinks.json. Once verified, the OS routes matching URLs directly to your app without a chooser dialog.
The user experience when App Links are correctly configured is better than Firebase Dynamic Links in one respect: there is no intermediate redirect. The URL goes directly to your app. Firebase Dynamic Links went through Firebase servers first, which added latency and a dependency on Google's infrastructure.
App Links require:
- HTTPS on your domain
- A valid
assetlinks.jsonfile signed with your app's SHA-256 certificate fingerprint android:autoVerify="true"on your intent filters- Android 6.0 (API 23) or higher for the auto-verification behavior
For the full setup process, see our Android App Links documentation and the complete guide to Android App Links.
Feature-by-Feature Comparison
| Feature | Firebase Dynamic Links | Android App Links |
|---|---|---|
| Direct app routing (app installed) | Yes (with redirect) | Yes (direct, no redirect) |
| Deferred deep linking (app not installed) | Yes | No (requires separate solution) |
| Short link generation | Yes | No |
| Cross-platform routing | Yes | Android only |
| Custom domains | Yes (paid) | Yes (your own domain) |
| Click analytics | Basic | None (requires your own) |
| Server dependency | Firebase (now defunct) | Your own server |
| Works offline | No | Yes (once verified) |
| Cost | Was free | Free (your infrastructure) |
| Status | Deprecated, shut down | Active, supported by Google |
The gap that stands out immediately is deferred deep linking. If your app acquisition funnel relied on Firebase to remember where a user was trying to go before they installed your app, you need a replacement.
What You Actually Lose
Deferred deep linking. This is the real loss. Android provides no built-in mechanism for storing a destination URL and replaying it after install. You need either a fingerprinting approach (matching device characteristics across click and install), a Play Store referral approach using the Install Referrer API, or a platform that handles this for you.
Short links. App Links work with your full domain URLs. If you relied on yourapp.page.link short links, you need a different URL shortening solution.
Cross-platform link handling. App Links are Android-specific. If you send the same link to iOS and Android users, iOS users need Universal Links set up separately.
Built-in analytics. App Links give you no click data. Attribution requires separate instrumentation.
The Migration Path
Google's own migration guidance recommends moving to native App Links for the core linking behavior. For deferred deep linking specifically, Google points developers toward their Play Referrer API as a first-party option, though it only works for installs originating from the Play Store.
For a complete replacement that covers deferred deep linking, cross-platform routing, and analytics, a dedicated deep linking platform makes sense. Tolinku provides all of these capabilities and handles the Asset Links hosting, verification, and deferred linking infrastructure. See the migration guide from Firebase Dynamic Links for a step-by-step walkthrough.
If your use case is simple (users with the app installed clicking links), native App Links alone may be sufficient. If you had users clicking links before installing and expected them to land in the right place after install, you need something beyond App Links.
Setting Up Native App Links as Your Foundation
Regardless of what you choose for deferred linking, Android App Links should be the foundation. Here is the basic intent filter configuration for your AndroidManifest.xml:
<activity android:name=".MainActivity">
<intent-filter android:autoVerify="true">
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data
android:scheme="https"
android:host="yourdomain.com" />
</intent-filter>
</activity>
Your assetlinks.json needs to be accessible at https://yourdomain.com/.well-known/assetlinks.json:
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.yourcompany.yourapp",
"sha256_cert_fingerprints": [
"AA:BB:CC:..."
]
}
}]
You can get your SHA-256 fingerprint from the Play Console under Setup > App integrity, or from your keystore directly:
keytool -list -v -keystore your.keystore -alias your-alias
Verification and Testing
Unlike Firebase Dynamic Links, where Google managed verification, App Links verification is your responsibility. Android checks your assetlinks.json when the app is installed or updated, and periodically thereafter.
Test verification with the Android Debug Bridge:
adb shell pm get-app-links com.yourcompany.yourapp
A verified state shows VERIFIED for each domain. If you see FAILED, check:
- The file is reachable over HTTPS with a 200 response
- Content-Type is
application/json - The SHA-256 fingerprint matches your production signing certificate (not your debug keystore)
- No redirects on the
/.well-known/assetlinks.jsonpath
For detailed troubleshooting steps, see our Android deep linking troubleshooting guide.
Performance Difference
One concrete improvement moving from Firebase Dynamic Links to native App Links: speed. Firebase Dynamic Links routed through Firebase servers, which meant a round trip before your app opened. Depending on network conditions, this could be noticeable.
Native App Links have no intermediate server. The OS opens your app directly. From a user perspective, clicking a link and arriving in your app is faster.
This matters most in high-intent flows: payment links, invitation links, promotional codes. Every extra second of load time in these flows loses conversions.
Making the Decision
If you are still running Firebase Dynamic Links and facing the migration, here is a practical framework:
Choose native App Links only if:
- You do not need deferred deep linking (your users always have the app before clicking links)
- You do not need iOS support from the same link
- You are willing to build your own analytics
Choose native App Links plus a deep linking platform if:
- You need deferred deep linking (the most common case)
- You want cross-platform links that work on iOS and Android
- You want attribution data and analytics
- You want to avoid maintaining the Asset Links infrastructure yourself
The one option to avoid: doing nothing. Firebase Dynamic Links are gone. Links using the Firebase domain are broken. Every day you delay is users hitting dead links.
What Happens to Existing Firebase Dynamic Links
Any links using the page.link domain are broken as of the shutdown date. If you distributed these links in emails, social posts, QR codes, or SMS campaigns, those links no longer work.
For links you control, update them to use your own domain with proper App Links configuration. For links you cannot update (printed materials, old social posts), set up redirects at the Firebase domain level if that is still possible, or accept that historical links are lost.
Going forward, owning your domain for deep links is better practice regardless. A yourapp.com/share/xyz link you control is always preferable to a third-party domain you depend on. Firebase Dynamic Links taught many teams this lesson the hard way.
Summary
Android App Links is the right technical foundation for Android deep linking in 2026. It is native, fast, and actively supported by Google. The gaps versus Firebase Dynamic Links are real, particularly deferred deep linking, but they are solvable.
The migration path is: implement App Links for the core linking behavior, then decide based on your needs whether to add a deep linking platform for deferred linking, cross-platform support, and analytics.
See our deep linking platform comparison for more context on evaluating your options, and the configuring Android guide for setup instructions.
Get deep linking tips in your inbox
One email per week. No spam.
