Open in app from web: the patterns that work in 2026

scope

A practical guide to opening a mobile app from a web page, the right way in 2026. Covers iOS Universal Links, Android App Links, intent URLs as a fallback, and the in-app-browser edge case where everything breaks.

Cluster C hub: /guides/firebase-dynamic-links-replacement.

the problem

User is reading a web page in a browser. There's a button that says "Open in App." Tap it. Three outcomes are possible:

1. App is installed → opens directly to the right screen.
2. App is not installed → user goes to the App Store or Play Store, installs, opens app at the right screen.
3. Something in the middle goes wrong → user sees a system error, a stuck browser, or the wrong destination.

The history of mobile deep linking is the history of making outcome 3 less common. The current state of the art:

the modern pattern

For an inbound web link that should open the app if installed:

1. Use an HTTPS URL on a domain you control.
2. Register the URL pattern as a Universal Link on iOS and an App Link on Android.
3. Serve the AASA file at /.well-known/apple-app-site-association and the assetlinks.json file at /.well-known/assetlinks.json on the domain.
4. On the web page, render a normal <a href="https://yourdomain.com/path"> link.
5. If the user has the app installed, the OS routes the tap to the app. If not, the URL falls back to web.

That's the whole pattern for the common case. The complications are at the edges.

Setup walkthroughs: /guides/ios-universal-links-setup, /guides/android-app-links-setup. File formats: /guides/aasa-file-explained, /guides/assetlinks-json-explained.

the iOS path, in detail

iOS Universal Links work cleanly when the user taps the link in:

• Safari (system browser)
• Mail
• Notes, Messages, third-party messaging apps
• A push notification's tap action

They do NOT work cleanly when the user taps the link inside:

• A WKWebView instance hosted by another app (Instagram, TikTok, Facebook, Messenger, Threads, etc.)
• The link's first-tap behavior inside a UIWebView (legacy)
• Some App Clips contexts

The in-app browser failure mode is the most common headache. From inside Instagram's webview, an HTTPS Universal Link does not trigger the OS-level handoff to the app. The host webview consumes the navigation and renders the URL as a web page instead.

This is the failure category the /guides/in-app-browser-logged-out thesis addresses on the consumer side. For the engineering reason this happens: /guides/in-app-browser-cookies-explained.

If your app's primary inbound surface is social media, the in-app browser case dominates your "open in app" UX. Platform-specific escape mechanisms exist on both iOS and Android — workarounds that fire only when the host webview is detected and hand the user off to their real browser.

the Android path, in detail

Android App Links work cleanly when:

• The user taps a verified HTTPS URL on Chrome, Firefox, Samsung Internet, or any system browser.
• The user taps from Gmail, Messages, push notification, or another app's share sheet.
• The <intent-filter android:autoVerify="true"> is correctly declared and the assetlinks.json file is valid at install time.

They degrade or fail when:

• The assetlinks.json file fails verification (wrong package, wrong SHA-256 fingerprint, or 404). The link then surfaces the disambiguation dialog ("Open with") instead of opening the app directly.
• The user taps inside a WebView instance hosted by another app. Similar to iOS, the host app captures the navigation.

The Android-specific fallback for the unverified case is the intent URL scheme, which instructs Android to open a specified package or fall back to a supplied web URL. Detailed walkthrough: /guides/intent-url-android.

the working JavaScript pattern

Pseudocode for an "Open in App" button that handles all three outcomes:

function openInApp(path) {
    const ua = navigator.userAgent;
    const isIOS = /iPhone|iPad|iPod/i.test(ua);
    const isAndroid = /android/i.test(ua);
    const inAppBrowser = detectInAppBrowser(ua);

    if (inAppBrowser.detected) {
        // host webview will eat Universal Link / App Link
        // surface escape UI instead
        return surfaceEscapeUI();
    }

    if (isIOS) {
        // plain HTTPS URL triggers Universal Link
        window.location.href = `https://yourdomain.com/app/${path}`;
        return;
    }

    if (isAndroid) {
        // Android App Link with Play Store fallback
        // See /guides/intent-url-android for the full intent URL syntax
        window.location.href = `https://yourdomain.com/app/${path}`;
        return;
    }
    
    // desktop or other — open web URL
    window.location.href = `https://yourdomain.com/app/${path}`;
}

The detectInAppBrowser helper is the User-Agent parsing pattern: /guides/detect-tiktok-in-app-browser-useragent covers the regex set in detail.

edge cases

The user is on iOS but in Chrome (not Safari). Universal Links still work — Chrome iOS uses WKWebView underneath and honors the OS-level handoff. The exception is some configurations where Chrome treats the URL as a same-domain navigation; in that case use target="_blank" or window.open to force a new context.

The user is on Android but in a non-default browser. App Links work as long as the package and intent filter are correctly declared. Some browsers (notably Samsung Internet) require an explicit intent URL rather than relying on App Link verification.

The user has the app installed but it's not been opened recently. On iOS, Universal Links work regardless of last-open time. On Android, App Links work as long as the app is installed and the assetlinks.json verification succeeded at install time.

Universal Link is registered but the user has previously chosen "Open in browser" from the long-press menu on iOS 13+. iOS remembers the user's preference. Subsequent taps of the same Universal Link open in the browser, not the app. The user can reset via Settings → Apps → Your App → Universal Links.

The web page is itself loaded inside a WKWebView instance (e.g., your own app's in-app browser, or another app's). Universal Links do not trigger from inside a WKWebView. This is documented Apple behavior, not a bug.

the deferred install case

If the user doesn't have the app installed and you want them to land at /path after installing from the store, that's the deferred-deep-linking problem. Cleanly solvable on Android via Play Install Referrer; degraded on iOS post-ATT. Full mechanism: /guides/deferred-deep-linking-explained.

If you used Firebase Dynamic Links for this, the FDL shutdown August 2025 ended that path. Migration: /guides/firebase-dynamic-links-migration. Strategic options: /guides/firebase-dynamic-links-replacement.

when "open in app" is the wrong frame

For many web-to-mobile flows in 2026, the question isn't actually "how do I open the app?" — it's "how do I make the link work at all?" If your link is a bio link, a music release, a checkout URL, or a creator funnel that doesn't have a mobile app behind it, the relevant failure isn't deep-link routing — it's in-app browser cookie isolation.

The consumer-side failure: links tapped from inside Instagram or TikTok don't carry the user's logged-in session because the in-app webview has a separate cookie jar. Engineering breakdown: /guides/in-app-browser-cookies-explained. Thesis page: /guides/in-app-browser-logged-out.

This is the non-app side of the link-routing problem space, and the one linkboo addresses directly. The no-SDK linkboo path is at link.boo/api.

related dev reading

• Cluster C hub: /guides/firebase-dynamic-links-replacement
• iOS Universal Links: /guides/ios-universal-links-setup
• Android App Links: /guides/android-app-links-setup
• Universal vs deep vs app link: /guides/universal-link-vs-deep-link-vs-app-link
• Intent URL pattern: /guides/intent-url-android
• Deferred deep linking: /guides/deferred-deep-linking-explained
• Bridge: /guides/in-app-browser-logged-out

references

• Apple Universal Links documentation
• Android App Links Verification documentation
• Chrome for Android intent URL syntax
• Apple WKWebView Universal Link behavior