Universal Links vs App Links: Setting Up Deep Linking on iOS and Android

Your app runs on both iOS and Android. A user taps a link in your email, and it opens the app correctly on iPhone. The same link on Android opens a browser instead. Or the reverse. Half your users get a broken experience, and you are not sure which setup is responsible.

The cause is structural. iOS and Android each have their own native linking standard, and they do not cross over. Universal Links vs App Links is not a choice between two options. They are separate implementations for separate platforms. If you want to know how to handle deep linking across iOS and Android without losing users, the answer is: you need both. This guide explains what each standard does, how to set it up, where both fail, and how to decide what you need.

Key Takeaways

• Universal Links and App Links are platform-specific and non-interchangeable. A Universal Link configured for iOS will not open an Android app. Cross-platform coverage requires two separate implementations running in parallel.

• Both require a verified JSON file hosted on your domain. iOS uses the Apple App Site Association (AASA) file. Android uses assetlinks.json. Neither works without domain verification.

• In-app browsers break both on every platform. Links tapped inside Instagram, TikTok, Facebook, or LinkedIn bypass OS-level routing on iOS and Android alike. This is the most common failure for apps running paid social campaigns.

• Neither handles uninstalled-app journeys natively. When a user taps a link without the app installed, the intended destination is lost after the App Store or Play Store redirect. Preserving it requires a separate mechanism called deferred deep linking.

• Firebase Dynamic Links shut down on August 25, 2025 (Firebase Deprecation FAQ). Teams relying on it for cross-platform or deferred linking need a replacement.

What Are Universal Links and App Links?

Universal Links (iOS) and App Links (Android) are OS-level linking standards that open a specific screen inside your mobile app directly from a standard HTTPS URL, without routing through a browser first.

They were created to replace the earlier approach: URI schemes.

Why URI schemes fall short:

• Any app can register any custom scheme (e.g., myapp://). There is no ownership verification.

• Two apps can register the same scheme, causing silent conflicts.

• When the app is not installed, there is no reliable fallback. Users typically land on a blank screen or error page.

What Universal Links and App Links add:

• Domain-verified ownership. Only your app can handle links from your verified domain.

• A graceful fallback to your web URL when the app is not installed, typically a redirect to the App Store or Play Store.

1. How Universal Links Work on iOS

Universal Links are Apple's native standard, available on iOS 9 and later. When a user taps a Universal Link, iOS checks two conditions before routing the link into your app:

1. The app is installed on the device.

2. Your domain is verified for that app.

If both are true, iOS opens the app directly to the intended screen. If not, the link falls back to the web URL you configured.

Technical requirements:

• Verification uses a JSON file called the Apple App Site Association (AASA) file, hosted at /.well-known/apple-app-site-association (Apple Developer Documentation).

• The file must be served over HTTPS with no redirects on that exact path.

• The file must be under 128 KB uncompressed.

• Your Xcode project must declare the domain in the Associated Domains entitlement using the applinks: prefix.

• From iOS 14 onward, Apple fetches the AASA file through its own CDN rather than directly from your server. Updates can take several hours to propagate to new users.

2. How App Links Work on Android

Android App Links are Google's native standard, available on Android 6.0 (Marshmallow) and later. The mechanism works similarly: Android verifies domain ownership before routing links into your app.

Technical requirements:

• Verification uses a JSON file called assetlinks.json, hosted at /.well-known/assetlinks.json (Android Developers Documentation).

• The file must include your app's package name and the SHA-256 fingerprint of your release signing certificate.

• Your app manifest must declare android:autoVerify="true" on the relevant intent filters.

• Android verifies the domain at install time. Initial verification takes up to 20 seconds.

• From Android 15 onward, the system re-verifies domains periodically in the background. Changes to your assetlinks.json can take up to seven days to propagate across all devices.

Universal Links vs App Links: Setup Requirements Compared

Both standards share the same foundation: an HTTPS domain with a valid SSL certificate and a JSON verification file at a well-known path. Everything else is platform-specific.

1. Setting Up iOS Universal Links

Complete these steps in order:

1. Host the AASA file at https://yourdomain.com/.well-known/apple-app-site-association. Serve it with Content-Type: application/json, no redirects, and file size under 128 KB.

2. Define path patterns in the AASA JSON. Specify only the URL paths your app needs to handle. Avoid overly broad wildcards like /* unless you intend to intercept every path on your domain.

3. Add the Associated Domains entitlement in Xcode. Under Signing and Capabilities, add applinks:yourdomain.com. List each subdomain you want to support as a separate entry.

4. Enable developer mode for testing. In debug builds, set the entitlement to applinks:yourdomain.com?mode=developer. This bypasses Apple's CDN and fetches your file directly, making iteration much faster.

5. Check the cached version. Visit https://app-site-association.cdn-apple.com/a/v1/yourdomain.com to inspect what Apple's CDN is currently serving for your domain.

Most common mistake: A server-side redirect on the AASA file path. Apple's CDN crawler does not follow redirects. One redirect causes a silent verification failure with no error message.

2. Setting Up Android App Links

1. Create and host assetlinks.json at https://yourdomain.com/.well-known/assetlinks.json. Serve it with Content-Type: application/json. It must be publicly accessible without VPN or authentication.

2. Get the correct SHA-256 fingerprint. If you use Play App Signing, use the fingerprint from the Play Console under App integrity. This is different from your local keystore fingerprint.

3. Update the app manifest. Add android:autoVerify="true" and android:host="yourdomain.com" to the relevant <intent-filter>.

4. Handle multiple hostnames separately. If your intent filters declare more than one hostname, each needs its own assetlinks.json file. Android verifies each domain independently.

5. Validate with App Links Assistant. In Android Studio, go to Tools > App Links Assistant. It validates manifest declarations and lets you simulate link handling locally.

Most common mistake: SHA-256 fingerprint mismatch. Teams that migrated to Play App Signing often use their local keystore fingerprint instead of the Play Console value, which are different certificates.

For a detailed debugging walkthrough, the Android App Links setup guide covers fingerprint errors, redirect issues, and testing tools step by step.

Why Universal Links and App Links Break in Instagram, TikTok, and Facebook

This is the most common production failure for apps running paid social campaigns, and it affects iOS and Android equally.

What happens when a user taps your link inside a social app:

1. The user is inside Instagram, TikTok, Facebook, or LinkedIn.

2. They tap your link.

3. The link opens in that app's built-in browser (WKWebView on iOS, WebView on Android).

4. The embedded browser does not pass the link to the OS for native routing.

5. Universal Links and App Links only fire when the OS itself intercepts the tap. Inside a webview, the OS never receives it.

6. The user lands on your web page, not your app.

There is no server-side workaround. Both Apple and Android document that the OS only intercepts link taps originating outside webviews. Once a link opens inside an embedded browser, native routing is never triggered.

The fix: a three-layer linking setup

How to implement the URI scheme fallback:

1. Route your ad or email link to a lightweight landing page, not directly to app content.

2. On that page, detect the in-app browser context using the User-Agent string.

3. If an in-app browser is detected, show an "Open in [App Name]" button prominently.

4. Have that button trigger a URI scheme link (e.g., myapp://product/123).

5. URI schemes work inside webviews because they require an explicit user tap rather than automatic OS interception.

What Is Deferred Deep Linking, and Why Native Standards Skip It

Deferred deep linking is a mechanism that preserves an intended in-app destination across the app installation process. When a user taps a link and the app is not installed, deferred deep linking stores their destination, redirects them to the App Store or Play Store, and then routes them to the correct screen on their very first app open after install.

Neither Universal Links nor App Links provide this natively. They only handle routing when the app is already on the device. When the app is absent, both fall back to your web URL, and the link destination is gone after the app store redirect.

Why this matters for paid user acquisition:

Consider this sequence with and without deferred deep linking:

Paid acquisition volume is growing on both platforms. That growth raises the cost of every lost activation: more users arriving through paid campaigns means more first-opens where a missing deferred link drops the user on the wrong screen.

Deferred deep linking requires a third-party SDK or service. Apple and Google do not provide it as part of their native standards. For teams dealing with iOS-specific privacy changes since iOS 17 that affect deferred linking match rates, Airbridge's guide on deferred deep linking after iOS 17 covers the implications in detail.

Choosing Your Cross-Platform Setup

When to use a dedicated cross-platform tool:

Each of the three layers fails differently. The AASA file breaks on server-side redirects. The assetlinks.json breaks on SHA-256 fingerprint drift after every Play App Signing rotation. The URI scheme fallback breaks when Instagram or TikTok ships a new in-app browser User-Agent string. Re-testing each layer after every major iOS and Android release, and after each social app update, is the real ongoing cost. A dedicated tool consolidates all three into one link and handles those failure modes automatically.

Cross-Platform App Linking: The Bottom Line

Universal Links and App Links are the correct native foundation for in-app linking. They are platform-specific, non-interchangeable, and both required if your app runs on iOS and Android.

Getting cross-platform deep linking right involves three pieces:

1. Native Universal Links and App Links: domain verification on each platform separately. Both verification files share a single HTTPS domain, so the maintenance is lighter than it sounds.

2. URI scheme fallback: for in-app browser contexts across Instagram, TikTok, Facebook, and LinkedIn.

3. Deferred linking layer: for paid acquisition campaigns on either platform.

Start with the native setups, verify them end-to-end on both platforms, and add deferred linking once the foundation is solid.