Goal: a visitor on your website, or someone who taps a shared link, lands where they should: your app if it is installed, your store page if not.
Three pieces
- Smart App Banner (iOS). A banner Safari can show on your web page that opens or offers your app. It is set with a meta tag in the page head. This page does not cover the tag name, its fields or the browsers that honor it; check Apple's current documentation ("Promoting Apps with Smart App Banners") before you implement it.
- Deep link. A link that opens a specific screen in your app, not just its start screen.
- Android App Links. Web links (http/https) that open directly in your app once the system has verified that you control the domain.
Android App Links: what the official page says
Per Android Developers (retrieved 2026-10-24):
- If
android:autoVerify="true"is present in at least one intent filter, installing the app on Android 6.0 (API 23) or higher makes the system automatically verify the hosts in your intent filters. - For each hostname, Android queries a Digital Asset Links file at
https://hostname/.well-known/assetlinks.json. - The system only inspects intent filters with action
android.intent.action.VIEW, categoriesBROWSABLEandDEFAULT, and anhttporhttpsscheme.
Steps
- Decide the destinations. Home, a product, an invite, a content item. Write the URL pattern for each, for example
/item/123. - Make a web fallback. The same URL must open a useful page for people without the app, with a store button. See app landing page structure.
- Set up Android. Add the intent filter with autoVerify and host the assetlinks.json file on your domain, as described above.
- Set up iOS. Add the banner meta tag, and, for links that open the app directly, associate your domain with the app. Use Apple's current documentation for the exact files and entitlements.
- Handle the link inside the app. Read the path and open the right screen. Show a sensible screen if the content no longer exists.
Test steps
On Android, after installing the app, wait for the asynchronous verification (the official page says at least 20 seconds), then check the state:
adb shell am start -a android.intent.action.VIEW \
-c android.intent.category.BROWSABLE \
-d "https://your.domain/item/123"
On Android 12 or higher you can trigger and read verification manually with adb shell pm verify-app-links --re-verify PACKAGE_NAME and adb shell pm get-app-links PACKAGE_NAME. A domain that passes shows verified; none can mean verification has not finished.
Test matrix, each on a real device:
| Case | Expected |
|---|---|
| App installed, tap link in a browser | Opens the right screen |
| App not installed | Web page with store button |
| Link from a messenger or social app | Opens, or falls back to the web page |
| Link to deleted content | Friendly message, not a crash |
| Fresh install, then tap | Store page first; opening after install shows the right content only if you built deferred routing |
Test on each OS version you support. In-app browsers and some messengers handle links differently, so test those too.
Pitfalls
- A wrong or unreachable assetlinks.json, or one hosted behind a redirect.
- Links that work only on your test device.
- Forgetting the web fallback.
- Different behavior between debug and release signing; check the certificate fingerprint in your file.
Ask for private, structured feedback from testers on real devices who try your links.
Related: app press kit, waitlist page, hub App Store optimization and launch.