Your Universal Links work in Safari. They work in Chrome. They work when you test them on your phone. But the moment a real user taps your link inside Instagram or TikTok, they land on a web fallback page instead of your app. This is the single most common deep linking failure in production, and it affects every app that runs paid social campaigns.
The frustrating part is that everything looks correct in your test environment. Your apple-app-site-association (AASA) file validates. Your assetlinks.json passes Google's verification tool. Your QA team confirms the links work. But in production, where 40-60% of your paid social traffic opens links inside an in-app browser, users hit a dead end. They see your mobile website instead of your app, and your conversion rate drops accordingly.
This guide breaks down exactly why in-app browsers break Universal Links and App Links, how to diagnose which failure mode you are dealing with, and the tested workarounds for every major platform.

How Universal Links and App Links Are Supposed to Work

Before diagnosing what breaks, it helps to understand the mechanism that is supposed to work.
On iOS, Universal Links rely on the apple-app-site-association (AASA) file hosted on your domain. When a user taps a link, iOS checks whether that domain has a valid AASA file associating it with an installed app. If it does, the OS intercepts the link and opens the app directly, passing the URL path as context. The key detail: this interception happens at the OS level, before any browser renders the page.
On Android, App Links work similarly through the assetlinks.json file. When a verified App Link is tapped, Android routes the user to the app without showing a disambiguation dialog. The verification is tied to the domain, the package name, and the signing certificate.
The critical distinction that explains most breakage is this: both systems were designed for links tapped in first-party browser contexts (Safari, Chrome, the home screen). They were not designed for, and do not reliably work inside, embedded WebViews that social media apps use as their in-app browsers.
For a thorough primer on how all deep link types work, the complete guide to deep links covers URI schemes, Universal Links, App Links, and deferred deep links in detail.

Why In-App Browsers Break Everything

Instagram, TikTok, LinkedIn, X (formerly Twitter), Facebook, and Snapchat all use embedded browser views instead of handing links to the system browser. On iOS, this is typically a WKWebView or SFSafariViewController. On Android, it is a Custom Tab or a raw WebView. Each of these behaves differently from the system browser in ways that break deep linking. If this feels like the platforms are actively working against you, that is because their incentives are to keep users inside their app ecosystem, not route them to yours.
WKWebView does not trigger Universal Link interception by default. When Instagram opens a link in its embedded browser, iOS treats it as a web page request inside the app, not as a link tap that should trigger the OS-level interception. The AASA file is irrelevant here because the system never gets the chance to check it. The link simply loads as a web page.
JavaScript redirects do not count as user-initiated taps. Apple specifically requires a "user-initiated" navigation for Universal Link interception. If your link handler uses a JavaScript redirect (window.location.href) to route users, iOS ignores it. The tap must be a direct, user-initiated click on an anchor tag pointing to your Universal Link domain. This is sometimes called Apple's "click-gate" behaviour.
Android Custom Tabs vs WebView handling differs significantly. Android Custom Tabs (used by some apps) do support App Links interception in most cases. But raw WebViews (used by others) do not. The same link can work when opened from one social app and fail when opened from another, depending on which browser component that app uses.
Platform-specific quirks compound the problem. Instagram changed its in-app browser behaviour in 2025, affecting how redirects are handled. TikTok is known to strip certain URL parameters in some configurations. Facebook's in-app browser adds its own tracking parameters that can interfere with deep link routing. Each platform introduces its own edge cases.

Diagnosing Which Failure Mode You Have

Not all in-app browser failures are the same. Identifying your specific failure mode determines which fix to apply.
Failure mode 1: AASA file not being fetched. Your association file exists but is not reachable by Apple's CDN. Common causes include aggressive CDN caching (CloudFront, Cloudflare) serving a stale or malformed version, incorrect content-type headers (must be application/json), or the file not being at the correct path (/.well-known/apple-app-site-association). Use Apple's AASA validator and check your CDN cache headers to diagnose.
Failure mode 2: Link opens but app does not launch. The web page loads correctly in the in-app browser, but the OS never intercepts the navigation to open your app. This is the most common failure you will encounter and is caused by the WebView context blocking OS-level interception. Your AASA file is fine. The browser environment is the problem.
Failure mode 3: App launches but context or parameters are lost. The app opens, but the user lands on the home screen instead of the intended in-app destination. This happens when the deep link URL is intercepted but the path or query parameters are stripped during the redirect chain. Check your server-side redirect configuration and ensure parameters survive every hop.
Failure mode 4: Works on iOS but fails on Android (or vice versa). Cross-platform inconsistency usually points to a configuration issue specific to one OS. Verify your assetlinks.json separately from your AASA file. Check that your Android intent filters match the exact URL patterns you are using. Confirm SHA-256 certificate fingerprints are current (they change with app updates if signing keys rotate).
Quick diagnostic checklist:

1. Does the link work in Safari/Chrome on the same device? (If no, the issue is your AASA/assetlinks config, not the in-app browser.)

2. Does the link work in the in-app browser of every social platform, or only some? (Platform-specific means you need platform-specific fixes.)

3. Does the app launch but lose context? (Redirect chain or parameter stripping issue.)

4. Did it work before a recent OS or app update? (Regression caused by platform changes.)

5. Does the AASA/assetlinks file validate with official tools? (Configuration file issue.)

Proven Workarounds for Each Platform

The intermediary page pattern is the most reliable universal fix for in-app browser failures. Instead of linking directly to your app's Universal Link domain from social ads, link to an intermediary web page. This page detects the user's environment (in-app browser, OS, device) and presents a clear call-to-action button with simple, obvious messaging like "Open in App". When the user taps that button, it triggers a navigation to your Universal Link domain as a user-initiated tap, which the OS can intercept and route to your app.
This pattern works because it converts the initial in-app browser load (which cannot trigger Universal Links) into a deliberate user tap (which can). The tradeoff is one extra screen in the user flow, but the alternative is a broken experience that converts at near-zero. Users who see the intermediary page understand they need to tap to continue, so the interaction feels intentional and natural.
For social media platforms specifically, routing organic social traffic into your app requires similar intermediary page tactics, and the patterns overlap significantly with paid campaign deep linking.
Custom URI schemes as a WebView fallback. Inside WebViews where Universal Links cannot fire, custom URI schemes (yourapp://path) can sometimes be triggered via JavaScript. The caveat: URI schemes show an error dialog if the app is not installed, and they do not support deferred deep linking. Use them only as a secondary fallback for users you can verify already have the app installed.
Platform-specific fixes:

• Instagram: Use the intermediary page pattern. Instagram's WKWebView blocks Universal Links on direct navigation.

• TikTok: Encode critical context in the URL path, not query parameters. TikTok strips certain query values.

• Facebook: Server-side parsing should be permissive. Facebook appends fbclid parameters that your routing must tolerate.

• LinkedIn: Use the intermediary page pattern. LinkedIn's browser blocks Universal Link interception on initial load.

• X: X opens links in SFSafariViewController, which supports Universal Links. Test it separately, as it may work without an intermediary page.

• Snapchat: Test after every Snapchat app update. Its in-app browser behaviour changes frequently.
  Server-side redirect chains can help when you control the entire redirect flow. Instead of client-side JavaScript redirects, use HTTP 302 redirects from your server. Some in-app browsers handle server-side redirects more gracefully than JavaScript-based navigation because the routing decision happens before the page renders. However, chaining more than two redirects often causes failures, so keep chains short and use server-side logic to preserve all URL parameters.

How to Test Deep Links Across Every In-App Browser

Testing deep links once in Safari is not testing. That is testing Safari. You need a systematic test matrix that covers the environments your actual users encounter.
Build a test matrix with these dimensions: platform (Instagram, TikTok, Facebook, LinkedIn, X, Snapchat), browser context (in-app browser vs system browser), OS version (current and one version back for both iOS and Android), and link type (Universal Link, App Link, custom URI scheme, deferred deep link).
For a typical app running social campaigns, this matrix has 50 or more test combinations. You do not need to test every combination before every release, but you should cover the top 10 combinations that represent 80% of your traffic.
Manual testing workflow: Create a set of test links that route to a specific, identifiable in-app screen (not the home screen). Share each link via the actual social platform (post it to a private Instagram story, send it in a TikTok DM, LinkedIn message, etc.). Tap the link from within the social app, not from a notes app or message. Verify the app opens and the correct screen loads. Document the result per platform, per OS version, including whether any parameters or context survived the journey.
Regression testing after OS updates is essential. iOS and Android releases frequently change WebView behaviour, Universal Link handling, and AASA caching logic. After every major OS update (iOS 18.x, Android 15), re-run your top 10 test combinations. Social apps also update their in-app browsers independently of the OS, so monitor those update cycles too.
Monitor deep link success rates in production. Track the ratio of link clicks to app opens per source platform. A sudden drop in this ratio for a specific platform signals a breakage. Set alerts for any source where the click-to-open ratio drops below your baseline by more than 15%.

Preventing Future Breakage: Architecture Decisions That Help

The platforms that break deep linking will continue to change their behaviour. Building resilience into your architecture saves you from firefighting after every update.
A dedicated deep linking service handles edge cases your custom code won't. Maintaining platform-specific workarounds for six or more social apps, across two operating systems, with behaviour that changes every few months, is a significant engineering burden. This is one of the non-negotiable features a deep linking tool must provide: in-app browser detection and routing that adapts to platform changes without requiring your engineering team to ship code.
Linkrunner's deep linking infrastructure handles in-app browser edge cases by default through its intermediary page routing and server-side detection, so teams do not need to build and maintain platform-specific workarounds manually.
Server-side routing beats client-side detection. When you detect the user's environment on your server (via user-agent parsing and request headers) rather than in JavaScript on the client, you can make routing decisions before the page renders. This is faster, more reliable, and less susceptible to JavaScript execution issues in restricted WebView environments.
Keep your AASA and assetlinks.json files healthy. Validate them monthly with Apple's and Google's official tools. Set CDN cache TTLs to no more than 24 hours for these critical files to ensure updates propagate quickly. Monitor HTTP response codes on the file paths continuously. A single hour of a 404 on your AASA file can cause Apple's CDN to cache the failure for days, breaking all Universal Links until the cache expires.
Build alerting for deep link failure rate spikes. Track click-to-app-open ratios by source platform in your analytics. Set up alerts when any platform's ratio drops by more than 15% from its 7-day rolling average. This catches breakage from platform updates before it affects a full campaign cycle.

Frequently Asked Questions

Why do Universal Links work in Safari but not inside Instagram?
Safari triggers OS-level interception. Instagram's WKWebView does not, so links load as web pages instead of opening your app.
Do Android App Links have the same in-app browser problems as iOS Universal Links?
Yes. Custom Tabs support App Link interception, but raw WebViews do not. The intermediary page pattern fixes both.
How do I test deep links inside TikTok's in-app browser?
Post your test link to a private TikTok video or send it via DM. Tap it from within TikTok, not from a notes app. Verify the app opens and parameters survive.
Can I use URI schemes as a fallback when Universal Links fail in WebViews?
Yes, but only for users you can verify already have the app. URI schemes show an error popup if the app is not installed and do not support deferred deep linking.
How often do in-app browser behaviours change after OS or app updates?
Frequently. Test after every major iOS and Android release and every significant Instagram, TikTok, and Facebook update. Re-run your full test matrix at least quarterly.

What We'd Do First

In-app browser breakage is not a bug you fix once. It is an ongoing operational challenge that requires monitoring, testing, and architectural resilience. If we had to fix one thing today, it would be the intermediary page for your highest-traffic social source. Get that working and you have solved the breakage for 60-70% of your affected users. Then build monitoring and testing infrastructure to catch the next breakage before your users do.
If maintaining platform-specific workarounds is consuming too much engineering time, a dedicated deep linking platform like Linkrunner handles in-app browser routing out of the box and adapts to platform changes without requiring your team to ship code for each update. Request a demo to see how it handles your specific traffic sources.