Universal Links are iOS's verified HTTPS deep links, and App Links are Android's equivalent. They are platform-specific and not interchangeable, so you must implement both to get seamless web-to-app behavior on every device. Your immediate action is the same on both sides: host a verification file on your domain and add the matching entitlement or manifest entries to your app.
TL;DR:
- Publish valid AASA JSON under 128 KB at the domain root or at /.well-known/; Apple's CDN may take hours or days to refresh.
- Android 15 lets you change path rules in assetlinks.json without an app release, but verification can take up to 7 days to propagate.
- When Play App Signing is enabled, use the fingerprint for Google's signing key in assetlinks.json; a local upload key can silently fail verification.
- Teams needing deferred attribution must build install referrer handling or choose a third party partner because neither platform preserves context across installation.
- Verify links for your highest traffic acquisition sources first, because failed verification can send people to the browser instead of the app.
Table of Contents
- What deep links are and where each verified type fits
- How iOS Universal Links are set up and where they fail
- How Android App Links are set up, including Android 15 changes
- Where runtime behavior and user experience diverge
- How to test and troubleshoot verification
- A practical checklist for shipping both
- What growth teams should prioritize
- Turn verified links into creator-driven installs
- FAQ
- Sources
What deep links are and where each verified type fits
A deep link is any URI that opens specific content inside an app instead of just launching it. Custom schemes such as myapp:// are the oldest form, but any app can register the same scheme, so they are unreliable for routing from the web. Android's own codelab notes that custom schemes remain useful for internal app navigation but not for web-to-app routing.
Universal Links and App Links solve this by using ordinary HTTPS URLs tied to a file you host. Here is what that buys you:
- Better UX: a verified link skips the browser or chooser and opens the app directly.
- Security: only the app named in your verification file can claim your domain.
- One URL per piece of content: the same link works in the app and falls back to the website.
- Platform split: iOS uses an apple-app-site-association (AASA) file, while Android uses assetlinks.json.
How iOS Universal Links are set up and where they fail
Apple's Universal Links documentation defines two requirements: an entitlement in the app and a verification file on your server. Work through them in this order:
- Add the Associated Domains capability in Xcode and list each host with the
applinks:prefix, for exampleapplinks:example.com. - Check that your app is configured for Associated Domains.
- Publish the AASA file over HTTPS at the domain root or under
/.well-known/, as valid JSON no larger than 128 KB. - Define which URL paths the app should claim, and exclude the ones it should not.
- Install the app on a device and test a Universal Link.
If verification fails, iOS quietly opens the URL in Safari. When Universal Links have been disabled for a domain, users can often re-enable them through a Smart App Banner on the site.
Caching is the most common surprise. Apple's QA1916 troubleshooting note explains that AASA files are cached on Apple's CDN, so updates can take hours or days to propagate.
Pro Tip: Validate your AASA JSON before deploying, since invalid JSON can prevent verification.
How Android App Links are set up, including Android 15 changes
Android App Links are a verified form of web link built on Digital Asset Links. The system checks a hosted assetlinks.json, and when it matches, links route straight to the app without the disambiguation dialog. Setup runs in this order:
- Add an intent filter to the relevant activity with
android:autoVerify="true", as the App Links verification guide requires. - Include
dataelements for bothhttpandhttps, and use separate intent filters when you declare distinct URL patterns. - Host the
assetlinks.jsonverification file on every host the app claims. - Put the app's SHA-256 signing certificate fingerprint in that file.
- Install the build and confirm the link opens the app.
Android 15 adds dynamic App Links rules, so you can update path matching in assetlinks.json without shipping an app release. The tradeoff is timing: on Android 15 and later, verification can take up to 7 days to propagate through periodic re-verification, while older versions generally check only at install or update.
Pro Tip: If you use Play App Signing, put the Google-managed signing key fingerprint in assetlinks.json, not your local upload key.
Where runtime behavior and user experience diverge
The two systems share a goal but fail differently, and that shapes which channels you can trust.
- Android failure mode: an unverified link triggers a disambiguation dialog or a browser fallback. Android's guidance calls that dialog the main friction App Links remove, because verification makes your app the default handler.
- iOS failure mode: a failed verification gives no dialog at all. The URL opens in Safari, and the user may never know an app was available.
- Verification decides everything: on both platforms, the verified association is what separates opening the app from opening the website.
- No deferred deep linking: neither system carries link context across an install. With some hosted solutions being retired, Firebase's Dynamic Links guidance points developers toward platform-native links, and teams must build install-referrer plumbing or use a third-party attribution partner.
The practical consequence: verify both platforms for your highest-value acquisition channels, such as email, SMS and paid social, where a silent fallback means a lost user.
How to test and troubleshoot verification
Most failures come from a short list of causes. Run this sequence before debugging anything exotic:
- Confirm the verification file is reachable over HTTPS and returns valid JSON.
- Check that the entitlement or manifest entry lists the exact host, including subdomains.
- On Android, compare the SHA-256 fingerprint in assetlinks.json with the one shown in the Play Console. Android's troubleshooting guide warns that a mismatch causes silent verification failures.
- On iOS, run the AASA file through Apple's validator and allow time for CDN propagation.
- Read logcat output on Android for verification results after install.
- Reinstall the app to re-trigger verification.
Common fixes include checking the AASA file and using the Play signing fingerprint.
Pro Tip: Test on a clean device with the app uninstalled, then installed, since cached verification state hides real problems.
A practical checklist for shipping both
Follow this order and you will avoid most rework:
- Stabilize your domain: canonical HTTPS URLs and a consistent path structure.
- Host the AASA file and assetlinks.json at their correct locations, and test that both are publicly reachable.
- Add the associated-domains entitlement on iOS and intent filters with
autoVerifyon Android. - Test on real devices with the app installed and uninstalled, and re-verify after every change.
- Add install-first context only where needed. Attribution matters here, and marketing attribution models are a useful background read before you choose a partner. Our guide to creator attribution for apps covers the practical side.
What growth teams should prioritize
Verify links for your highest-traffic sources first, because that is where a silent browser fallback costs the most installs. If post-install context matters, invest in install-referrer plumbing or a partner solution early, since neither platform gives you deferred linking. Finally, keep engineering, product and growth aligned on stable URL structures, and monitor verification health after every release.
— Jax
Turn verified links into creator-driven installs
Correct deep links only pay off when traffic reaches them. We run a commission-only creator network for consumer tech apps, where creators produce native content and we manage the strategy and distribution behind it. If you want to see how that plays out in practice, our creator landing pages guide covers campaign setup, and our case studies show creator-led results. To talk through your own app, start at Cultmedia.

FAQ
What is the difference between a deep link and a universal link?
A deep link is any link that opens specific content in an app, including custom schemes. A Universal Link is Apple's verified, HTTPS-based version that opens your app directly and falls back to your website when the app is missing.
Which file verifies Android App Links?
Android uses an assetlinks.json verification file hosted on your domain. It lists your app's package name and SHA-256 signing fingerprint so the system can confirm your app owns the links.
Why do my Universal Links open in Safari?
Usually verification failed or the AASA file is still cached on Apple's CDN. Validate the JSON, confirm the entitlement lists the exact host, and wait for propagation.
Do Universal Links and App Links support deferred deep linking?
No. Neither platform preserves link context across an install, so you need install-referrer handling or an attribution partner.
