You made a deep link, tapped it on your phone… and it opened the browser instead of the app. This is the single most common deep-linking problem, and it almost always comes down to one of a handful of causes. Here are 11 of them, most common first, with the fix for each.
1. The app simply isn't installed
Obvious, but check first. A raw scheme link (myapp://…) has no fallback, so if the app isn't there it fails to the browser (or an error). The fix is a link with an app → store → web fallback so "not installed" sends people to the store, not a dead page.
2. No assetlinks.json (Android) or AASA (iOS)
Verified Android App Links need an assetlinks.json; iOS Universal Links need an apple-app-site-association file on your domain. Without them, the OS treats your https link as a normal web link and opens the browser. lynkily hosts both for you.
3. Wrong SHA-256 fingerprint or bundle/package ID
If your assetlinks fingerprint doesn't match your signing certificate (remember Play App Signing rewrites it), or the iOS appID has the wrong Team ID/bundle, verification silently fails. Re-check against Play Console → App integrity and your Apple Developer account.
4. The file is served wrong
The association file must be over HTTPS, with no redirect, Content-Type: application/json, and (for AASA) no .json extension. A 301 or an text/html content type breaks verification.
5. Missing autoVerify intent filter (Android)
Your launch Activity needs an <intent-filter android:autoVerify="true"> with the BROWSABLE category and your https host. Without it, Android never claims the link.
6. You're inside an in-app browser
Links opened from Instagram, TikTok, Facebook or WhatsApp run in an in-app webview that often blocks the jump to a native app. The fix: give people a real "Open in app" button to tap (a user gesture works where an auto-redirect is blocked), or "Open in Chrome/Safari". lynkily's interstitial shows exactly that button.
7. iOS cached an old AASA
iOS fetches the AASA at install time and caches it. If you fixed the file after installing, delete and reinstall the app (or use a fresh device) before testing.
8. The user long-pressed or chose "Open in browser"
If a user once picked "open in browser" for your domain, Android/iOS may remember it. Check the app's link-handling setting (Android: App info → Open by default → add links).
9. Auto-redirect without a user gesture
iOS Safari and in-app webviews frequently block a custom-scheme redirect that isn't triggered by a tap. Relying on an automatic window.location = myapp:// is unreliable — offer a button instead.
10. Custom scheme only (no Universal/App Links)
Schemes are brittle and unsupported in some contexts. Prefer verified Universal Links / App Links, and keep the scheme as a secondary path. See Universal Links vs App Links vs URL schemes.
11. No deferred handling for new installs
If someone installs from your link, the app opens to its home screen unless you recover the intended destination on first launch — that's deferred deep linking.
The shortcut
lynkily Deep Links handles the parts that cause most of these: it hosts your AASA + assetlinks.json, builds the app → store → web fallback into every link, and shows a tap-to-Open in app button that works even inside in-app browsers — plus analytics on which outcome each tap hit.