Deep links. Open the app. Fall back gracefully.
Universal Links and App Links manifests served from your custom domain. iOS opens your app on tap; Android does the same. Browser fallback on desktop.
- Universal Links (iOS) and App Links (Android) served from your domain
- Deferred deep links — context survives app install
- Smart platform detection with graceful fallbacks
- No SDK required — works with standard OS mechanisms
Universal Links & App Links
Manifest files, auto-served from your domain
iOS Universal Links require an apple-app-site-association file. Android App Links require assetlinks.json. Elido generates and serves both from your custom domain automatically — no separate hosting, no manual file management.
- iOS Universal LinksBundle ID + Team ID → AASA served at /.well-known/ automatically
- Android App LinksPackage name + SHA-256 fingerprint → assetlinks.json, HTTPS enforced
- Smart-link fallbackApp not installed → App Store / Play Store via rule-based routing
- UTM passthroughUTM parameters preserved to store URL — attribution doesn't break
- No SDK in your appOS-level interception only; intent-filter and continueUserActivity
{ "applinks": { "apps": [], "details": [ { "appID": "TEAMID.com.yours.app", "paths": [ "/product/*", "/referral/*", "/invite/*" ] } ] } }
[{ "relation": [ "delegate_permission/ common.handle_all_urls" ], "target": { "namespace": "android_app", "package_name": "com.yourcompany.app", "sha256_cert_fingerprints": [ "AB:12:CD:34:EF:56:..." ] } }]
Served from your custom domain automatically. Configure bundle ID + Team ID (iOS) or package name + SHA-256 fingerprint (Android) in domain settings — Elido generates and hosts both files.
Deferred deep links
Context that survives the install
When the app isn’t installed, the user goes to the store, installs, and opens the app. Deferred deep-linking passes the original deep-link context through that journey so the app can land the user on exactly the right screen after first launch.
- 01
Clicks link
User taps an Elido short link — from email, social, QR.
go.yourcompany.com/p/12345 - 02
No app → Store
App not installed. OS detects from AASA / assetlinks check. Falls back to App Store or Play Store.
iOS → App Store · Android → Play Store - 03
Installs app
User installs from the store. The install referrer carries the click context as a query parameter.
click_id + UTM preserved in referrer URL - 04
Opens app
App opens for the first time. MMP reads install referrer; maps click_id to the install event.
Appsflyer / Adjust / Branch picks it up - 05
Lands on exact page
App routes to the originally linked screen — product/12345 — as if the user had the app already.
product/12345 — context preserved through install
The click_id and UTM parameters from the original short link are passed as query parameters to the store URL. Mobile Measurement Platforms (MMPs) that capture the install referrer — Appsflyer, Adjust, Branch — can match the install to the originating click. Full deferred deep-linking (passing in-app context through install) requires the MMP SDK in your app; Elido covers the link layer.
Smart platform detection
One link. Three redirect paths.
The edge reads User-Agent and platform signals at the redirect layer — before any JS runs. iPhone gets Universal Links, Android gets App Links, desktop gets your web fallback. No JavaScript redirect delay; no client-side platform detection.
- UA parsing at the edge, sub-millisecond
- iOS → Universal Link interception by the OS
- Android → App Link interception via intent-filter
- Desktop → web URL, no store detour
- In-app browsers detected and redirected to system browser
- Composes with smart-link rules — geo + device + deep-link
What you can do
- Apple App Site Association
- Android Asset Links
- Smart-link rules for store fallback
- Tested with adb and xcrun
How deep links actually work — and where they break
Universal Links and App Links are OS-level mechanisms. The setup is simple; the edge cases are not. This covers the full picture.
apple-app-site-association served automatically from your custom domain
Universal Links require an apple-app-site-association (AASA) file at /.well-known/apple-app-site-association on your custom domain. iOS downloads this file when your app is installed; it maps your domain to your app's bundle ID and team ID. If the mapping is correct, tapping an HTTPS link on your domain in any iOS app (Safari, Mail, Twitter, Instagram) opens your app directly instead of going to a browser. Elido generates and serves the AASA file from your custom domain's well-known path automatically, based on the bundle ID and team ID you configure in domain settings. You don't host the file separately. iOS caches the AASA file and re-downloads it periodically; if you change your bundle ID configuration in Elido's domain settings, the new AASA is live in seconds, but iOS devices will pick it up on their next cache refresh (typically 24-48 hours, or on app reinstall). Tested against the Apple AASA validator on each Elido release.
assetlinks.json served automatically — SHA-256 fingerprint from your signing key
Android App Links require a Digital Asset Links file at /.well-known/assetlinks.json on your domain. The file maps your domain to your app's package name and the SHA-256 fingerprint of your signing certificate. Android verifies this file during app install and again periodically. Elido serves it from your custom domain automatically, based on the package name and SHA-256 fingerprint you configure. Android verification requires HTTPS (enforced by Elido's TLS on the custom domain) and the file must respond within a few seconds (also handled). One common failure mode: different signing keys for debug vs release builds have different SHA-256 fingerprints. Configure both fingerprints in Elido's domain settings if you're testing with a debug build; production builds only need the release fingerprint. Tested with adb shell pm get-app-links on each release.
App installed → deep link. App not installed → store. Desktop → web. UTM preserved throughout.
The fallback chain is set per-link or per-domain in Elido's settings. For a short link with deep-link config: if the OS intercepts the tap (app installed, domain verified), the app opens. If not (app not installed), the link opens in the browser; the browser destination should be your App Store / Play Store link or a web fallback. Smart-link rules handle this cleanly: configure a rule for iOS → App Store URL, a rule for Android → Play Store URL, and fallback to the web destination. UTM parameters from the original short link are preserved in the fallback URLs so attribution doesn't break when the user hits the store. Deferred deep-linking (passing a specific deep-link path through an install, so the app opens to the right screen after install) requires an SDK in the app — Elido doesn't provide this. For deferred deep-linking, you still need Appsflyer, Adjust, or Firebase App Distribution.
Post-install retargeting: click ID passed to the destination for attribution
On a deep-link redirect, Elido passes the click_id as a query parameter to the fallback URL. If the user lands in the App Store and installs the app, the click_id is in the referral URL but is not automatically propagated into the app after install — that requires SKAdNetwork on iOS or a deferred deep-link SDK on Android. What Elido does: passes the click_id and UTM parameters to the store URL so a mobile attribution platform (MMP) that's capturing the install referrer can pick them up. This works with Appsflyer and Adjust if you pass the click_id in the campaign parameter of the store URL. If you're not using an MMP, the click_id in the store URL is effectively lost after install.
Migrating from Firebase Dynamic Links (sunset 2025)
Firebase Dynamic Links was sunset by Google in 2025. Elido can handle the core pattern: a single HTTPS short link that opens the right screen in an installed app, falls back to the store, and falls back to web on desktop. Configure the AASA and assetlinks.json in Elido domain settings (replaces the Firebase hosting of these files), update your share links to point at Elido short links instead of page.link URLs, and configure fallback chain via smart-link rules. What Elido does not replicate: Firebase's deferred deep-linking (post-install deep link context via the Firebase SDK), and Firebase's App Distribution deep links. If your app relies on deferred deep-linking heavily, you'll need Appsflyer, Adjust, or Branch alongside Elido for the attribution layer. For apps that only need 'open the right screen if installed, else go to store', Elido replaces Firebase Dynamic Links fully.
Mobile teams using Elido deep links
Names are placeholders for now — real customer names land here as case studies are published.
“We migrated from Firebase Dynamic Links the week they announced the sunset. The AASA and assetlinks.json setup in Elido took half a day. The smart-link fallback chain replaced the Firebase SDK logic we had in the app for store routing.”
“Per-link click analytics on deep links told us that 35% of our share links were being clicked on desktop — we had no web fallback configured. Adding the fallback took 10 minutes; the share-link conversion rate went up because users who clicked from desktop could now complete the action.”
“We use Elido short links with deep-link config for referral programs. The UTM passthrough to the App Store URL means our MMP picks up the install referrer correctly — attribution works without custom SDK work on our end.”
Elido deep links vs Branch.io vs Adjust vs Firebase Dynamic Links (sunset)
Branch and Adjust are full mobile attribution platforms — more powerful for deferred deep-linking and MMP attribution. Elido is the right tool when deep links are part of a broader shortener setup, not the primary product.
| Feature | Elido | Branch.io | Adjust |
|---|---|---|---|
| Universal Links (iOS) | Auto-served AASA from your domain | Fully managed at scale | No — MMP only, not deep-link host |
| App Links (Android) | Auto-served assetlinks.json from your domain | Fully managed | No |
| SDK required in app | No — OS-level interception | Yes — Branch SDK | Yes — Adjust SDK |
| Deferred deep-linking | No — requires SDK in app | Yes — core feature | Yes — with Adjust SDK |
| Mobile attribution (MMP) | Click ID passthrough; MMP wiring manual | Native MMP — Appsflyer, Kochava integrations | Full MMP platform |
| UTM passthrough to store | Yes — via query param on fallback URL | Yes, with attribution context | Yes |
| Analytics on link clicks | ClickHouse — geo, device, per-link | Deep mobile attribution analytics | Install + event attribution data |
| Firebase Dynamic Links replacement | Yes for basic pattern; no deferred deep-link | Full replacement including deferred | Partial — MMP side only |
Deep links questions
Do I need a Branch SDK or any SDK in my app to use Elido deep links?
No. Elido deep links use iOS Universal Links and Android App Links — OS-level mechanisms. Your app just needs to handle the incoming URL in the standard iOS (scene:openURLContexts or application:continueUserActivity) or Android (intent-filter in manifest) way. No third-party SDK is installed; the OS handles interception based on the AASA and assetlinks.json files Elido serves from your domain.
What's the AASA setup flow?
In Elido domain settings → Deep links: enter your iOS app's bundle ID (e.g., com.yourcompany.app) and Apple Team ID (10-character string from your Apple Developer account). Elido generates the AASA JSON and serves it at /.well-known/apple-app-site-association on your custom domain. Verify it's reachable with curl before submitting your app to TestFlight or the App Store. iOS downloads the AASA file during app installation on devices running iOS 9+.
Can I have multiple apps on one domain?
Yes — the AASA file supports multiple app entries. Configure each app's bundle ID and Team ID in domain settings; Elido generates a combined AASA with all apps listed. Android assetlinks.json also supports multiple package name + fingerprint combinations. Common use case: main app and an App Clip, or main app and a widget extension.
Firebase Dynamic Links sunset — what's the migration path?
Replace page.link short URLs with Elido short links (your custom domain or Elido shared domain). Configure AASA and assetlinks.json in Elido domain settings. Set up fallback chain via smart-link rules (iOS rule → App Store, Android rule → Play Store, fallback → web). Update share link generation in your app to call Elido's create_link API instead of Firebase. What doesn't migrate: if your app relies on Firebase's deferred deep-linking (post-install intent passing), you'll need Branch or Adjust for that piece.
How do I test Universal Links before publishing to the App Store?
Use xcrun simctl openurl booted 'https://go.yourcompany.com/test-slug' with your app installed on a simulator. On a physical device with a debug build, long-tap a link in Safari and see if 'Open in Your App' appears. Apple also provides the App Association File Validator at developer.apple.com — paste your AASA URL and it checks reachability, Content-Type, and JSON validity. Elido's AASA passes all three checks.
What's deferred deep-linking and why doesn't Elido do it?
Deferred deep-linking passes context (e.g., 'user was viewing product ID 123') from the link click through an app install and into the app's first launch. It requires a fingerprinting or attribution SDK in the app (Branch, Appsflyer, Adjust) that matches the install to the click during the install process. Elido doesn't install SDK code in your app; we only serve the AASA and assetlinks.json. Without the SDK, there's no mechanism to pass context through an install. For the basic 'open the right screen if installed' use case, Elido is sufficient. For passing intent through install, you need an MMP.
Can I use deep links on Elido's shared domain (s.elido.me)?
No. Universal Links and App Links require your domain — you can't claim *.elido.me as a Universal Link domain for your app. Deep links require a custom domain on Pro or Business. The custom domain is what you configure in your AASA and assetlinks.json, and Elido serves those files from it.
How do I handle the case where the user's browser blocks the app intercept?
Some browsers (notably Chrome on Android pre-6.0, and some in-app browsers like Instagram's) block App Links or Universal Link interception. The fallback URL is what they see. For in-app browsers: redirect to the system browser first using an intent URL (Android) or a user prompt. For Instagram / TikTok in-app browsers: the standard approach is to show a 'tap to open in your browser' prompt. Elido doesn't inject this prompt automatically — the fallback URL is your destination, and you control what happens there.
Keep reading
Custom domain setup — required for deep links; AASA and assetlinks.json served from your hostname.
iOS → App Store, Android → Play Store, desktop → web — the fallback chain using smart-link rules.
How product teams use deep links alongside A/B variants and smart-link rules.
MMP integrations — Appsflyer, Adjust, and Branch for deferred deep-linking alongside Elido.