Deep links in in-app browsers

Definition

An in-app browser is an embedded webview inside another app that renders links without handing them to the operating system, which prevents Universal Links and App Links from ever reaching the app that claims the domain.

This is not a misconfiguration and there is no setting that fixes it. When a webview loads a URL itself, the OS is never asked "which app handles this", so the answer your association file provides is never consulted. It is the leading cause of deep links that work in every test and fail for a large share of real users, because engineers test from Notes and users tap from social feeds.

Why the OS is never consulted

A Universal Link works because a tap asks the operating system to resolve a URL, and the OS checks its association records before handing it to a browser. An in-app browser skips the question: the host app already has a webview open, and it loads the URL into it. There is no resolution step to influence.

The last row is the important one and the reason app behaviour varies so much. Android Custom Tabs is a genuine browser instance rendered inside another app, and it resolves App Links normally. A raw WebView looks nearly identical to a user and behaves completely differently. Which one an app chose is invisible from the outside, changes between releases, and is the whole explanation for "it works in one social app but not another".

Detecting that you are inside one

Since you cannot make the link work, the practical response is to know when you are inside a webview and change what the page does. Detection is user-agent sniffing, which is unreliable in principle and works well enough in practice because the tokens are stable and distinctive.

<script>
  // These tokens are stable enough to rely on, but they are vendor strings
  // and do change. Treat a miss as "probably a real browser" — the cost of
  // a false negative is a normal page, which is the correct fallback.
  var IN_APP = [
    'FBAN', 'FBAV', 'FB_IAB',   // Facebook
    'Instagram',
    'Line/',
    'Twitter',
    'LinkedInApp',
    'Snapchat',
    'Pinterest',
    'BytedanceWebview', 'musical_ly', // TikTok
    'KAKAOTALK',
    'WhatsApp',
    'WeChat', 'MicroMessenger'
  ];

  var ua = navigator.userAgent || '';
  var inApp = IN_APP.some(function (token) { return ua.indexOf(token) !== -1; });

  if (inApp) {
    document.documentElement.classList.add('in-app-browser');
  }
</script>

What to do with that signal depends on the platform, and the two are not symmetrical — Android has a real escape hatch and iOS does not.

<!-- Android only. An intent: URL asks the system to start an activity
     rather than navigate, so it can break out of a WebView that would
     otherwise swallow an https:// link. S.browser_fallback_url is used
     when nothing handles the intent. -->
<a href="intent://example.com/products/42#Intent;
         scheme=https;
         package=com.example.shop;
         S.browser_fallback_url=https%3A%2F%2Fexample.com%2Fproducts%2F42;
         end">
  Open in the app
</a>

What actually helps

Ordered by how much they are worth, which is roughly the reverse of how often they are attempted.

1. Make the web page good. The most valuable response by a distance. If a meaningful share of taps land on the web regardless of configuration, the destination page needs to work on its own — the content visible, the action completable, the app a suggestion rather than a requirement.
2. Show an explicit "Open in Safari" instruction when detection fires. Point at the overflow menu. It is a two-tap ask and users complete it when the reason is obvious, which is far better than a link that appears to do nothing.
3. Use an `intent://` URL on Android. A real escape hatch with a built-in fallback, and worth doing because it covers the platform where in-app browsers are most common.
4. Carry the destination across the install with [deferred deep linking](/deferred-deep-linking). If the user goes to the store from the web page, the context can survive even though the tap never reached the app.
5. Do not auto-redirect to a custom scheme on page load. It is suppressed in most webviews, fails with no error, and on the platforms where it is not suppressed it produces an error dialog for users without the app.

Testing for it

This class of failure is invisible to every command-line test, so it has to be tested the way it happens. It takes about ten minutes and is worth doing once per release rather than never.

• Post the link to a private Instagram story or a draft post and tap it from the app.
• Send it to yourself in WhatsApp and in a Slack DM — Slack uses a real browser handoff, WhatsApp does not, and the contrast is instructive.
• Put it in a LinkedIn message and a TikTok bio.
• Do all of the above on both platforms, since the same app frequently uses WebView on one and Custom Tabs on the other.
• Record which combinations open the app. That list is your real coverage, and it will not match what your association file implies.