Mobile app deep links

Deep links open native apps directly from a short URL. When the visitor has your app installed, the link launches the right screen inside the app. When they don't, it falls back to the App Store (iOS) or Play Store (Android) — or any other URL you configure.

What you need#

To use deep links, you need:

• An iOS app with Universal Links configured, OR
• An Android app with App Links configured, OR
• Custom URI schemes (myapp://) if you don't have Universal/App Links yet.

For Universal Links and App Links, you'll also need to publish association files (apple-app-site-association for iOS, assetlinks.json for Android) on your custom domain. Elido serves those for you automatically once you upload the file in Settings → Domains → Deep linking.

Configure deep links on a link#

1. Open the link's detail page → Targeting → Deep linking.
2. Toggle deep linking on.
3. Add an iOS configuration:
   • App ID — e.g. K72L8M4N9P.com.acme.myapp (the Team ID + bundle identifier from your Apple Developer account).
   • In-app path — what the app should route to. The path is appended to your universal link host; the SDK in the app reads it from the launch URL.
   • Fallback URL — where to send visitors who don't have the app. Usually your App Store listing.
4. Add an Android configuration:
   • Package name — e.g. com.acme.myapp.
   • In-app path — same idea as iOS.
   • Fallback URL — usually a Play Store URL with your package name.
5. Save. The link will now do device-based routing on every click.

What happens at click time#

The redirect handler returns an HTML interstitial that runs about 50 ms of JavaScript. The interstitial:

1. Detects iOS vs Android vs desktop.
2. On iOS: tries to open via Universal Link. If the OS opens the app, you're done.
3. On Android: same with App Links.
4. After 1.2 seconds with no app, the page redirects to the fallback URL.

Desktop visitors always hit the fallback URL directly — there's no app to open.

If a visitor is on a platform we don't recognise (web view in WeChat, etc.), the link falls back to the desktop destination. You can override this with smart-link rules.

URI scheme fallback#

If you don't have Universal Links / App Links set up, you can still use a custom URI scheme:

• iOS scheme: myapp://
• Android scheme: myapp://

The interstitial will attempt to open the scheme, and fall back to the App Store / Play Store after 1.2 seconds. The downside is the OS shows a "Open in My App?" confirmation on first launch, which Universal Links avoid.

Analytics#

Every click logs whether the app opened or the fallback was used. The link's Analytics → Deep linking tab shows the open-rate per platform — useful for measuring how well your association files are working.

Limits#

• One iOS config and one Android config per link.
• Deep linking is available on Pro and Business; the free plan only supports flat redirects.

Common gotchas#

Universal Links work on a real device but not in the simulator. This is expected — Apple's simulator can't fetch the AASA file. Test on a real phone.

The fallback URL opens before the app even tries. Some Android browsers (Samsung Internet, in particular) intercept the scheme before the OS sees it. Make sure your App Links setup is complete: domain verified, package name correct, SHA-256 fingerprint matches.

iOS sometimes shows a tap-target banner instead of opening the app. That's iOS's "Open in Safari → Smart Banner" treating the page as a generic site. Re-uploading the AASA file with the correct app ID usually fixes it.

The link opens the app, then the wrong screen. Your in-app routing isn't matching the path Elido is passing. Log the launch URL inside your app to confirm what you're actually receiving, then update the path config to match.