Why does my universal link open in Instagram's browser instead of my app?

Instagram's in-app browser decides whether to pass links to iOS, and it is widely reported to keep many links in its own web view. Apple says this support is up to third-party browsers, so your file cannot force it.

Can I detect an in-app browser and redirect automatically?

You can show a different landing page, but automatic redirects into apps are unreliable, and Chrome only launches apps from a user gesture. A visible button the user taps is the safer pattern.

Does intent:// work inside every Android in-app browser?

It is not documented for in-app browsers. Chrome documents the format, but each host app's web view may treat it differently, so test it per app.

Is there a server-side fix for in-app browsers?

No. AASA and assetlinks.json only declare which app owns a URL. The in-app browser decides whether to hand the link on, so mitigation happens on the page and in testing.

Should I avoid social links entirely?

No. Use a landing page that works on the web, add an explicit open-in-app tap, and measure results per app. Most of the value comes from making the web fallback good.

What are UTM parameters?

UTM parameters are tags added to the end of a link, such as utm_source and utm_campaign, that tell analytics tools where a visit came from. They let you see which campaign, channel and ad brought each visitor.

In-app browsers and deep links, what to do

Short answer: Social apps open links in their own web views, and those web views decide whether to hand links to your app. Apple only says universal link support is "up to third-party web browsers", and no social platform documents its behaviour. It is widely reported that links often stay on the web. Use a landing page with an explicit "Open in app" tap, an intent:// button on Android, a web fallback, and test in every app you run campaigns on.

What is an in-app browser?

In-app browser: a web view built into a social, messaging or email app that opens tapped links inside that app rather than in Safari or Chrome.

Instagram, Facebook, TikTok and LinkedIn are the best-known examples. Because the page loads inside another company's app, that app controls what happens to links on it.

Why do deep links stay on the web inside social apps?

Because the decision belongs to the host app, not to iOS, Android or your server. Your AASA and assetlinks.json files say which app owns a URL; they cannot make another app pass the URL on.

What is and is not documented:

Apple: its universal links technote says support in third-party browsers is "up to third-party web browsers". That is the only primary statement found.
Google: App Links resolve when a web intent is fired. Whether a web view fires one is the host app's choice.
Meta, TikTok, LinkedIn: no primary documentation found on how their in-app browsers treat universal links or App Links.

Everything below is widely reported developer practice, not platform documentation, and it changes as apps update.

What do developers report?

Links tapped in Instagram, Facebook, TikTok and LinkedIn often load the web page in the in-app browser.
Results reportedly vary by platform, app version and how the link is posted (bio, story, ad, comment, message).
Many in-app browsers offer a menu option to open the page in the system browser, which then behaves like a normal tap.
A second, explicit tap on a page inside the in-app browser is often reported to work better than the first tap from the feed.

Treat these as starting points for your own tests, not rules.

Which mitigation patterns help?

None of these is guaranteed. Combine them and measure.

1. Landing page with a clear tap

Send social traffic to a landing page that shows the content and an "Open in the app" button.
Point the button at a separate link domain, such as go.example.com, with its own AASA entry and assetlinks.json. A link to the same domain the user is already on is treated as same-domain navigation on iOS; see same-domain navigation.
Keep the page useful on its own, so users who never leave the in-app browser still get value.

2. intent:// on Android

Chrome documents an intent:// link format that names your package and a fallback URL. Chrome only launches apps from a user gesture, so put it behind a button, not an automatic redirect.

<a href="intent://product/1#Intent;scheme=https;package=com.example.app;S.browser_fallback_url=https%3A%2F%2Fexample.com%2Fproduct%2F1;end">
  Open in the app
</a>

S.browser_fallback_url sends users without the app to the web page. Whether a given in-app browser honours intent:// is not documented, so test it.

3. Always keep a web fallback

Every deep link URL should be a working web page.
Include a store link for users without the app, ideally with deferred deep linking so the destination survives the install.

4. Prefer verified https links over custom schemes

Google notes custom schemes can be claimed by other apps and have no web fallback. Verified universal links and App Links at least give the system a reliable owner when a hand-off does happen.

How do providers help?

Deep linking providers build these patterns into hosted link pages: branded link domains with AASA and assetlinks.json hosted, a landing step with an open-in-app tap, and store fallbacks with deferred routing. Options include Linkrunner, Branch, Airbridge and Adjust. None can change how a social app's web view behaves, so ask each how they test in the apps you use.

Where Linkrunner fits: Best for teams running social and influencer campaigns who want branded short links, web-to-app flows and deferred routing in one platform, with attribution on the same links.

How do you test in-app browsers?

Confirm the basics first: the link opens the app from Notes on iOS and with adb shell am start -W -a android.intent.action.VIEW -d "https://example.com/product/1" com.example.app on Android. Check the files with curl -I on each file URL and sudo swcutil verify on a Mac.
Post the link from a test account in each app you use: bio, story, post, ad preview and direct message where possible.
Tap it on real iOS and Android devices, with the app installed and uninstalled.
Record the outcome per app and placement: app opened, web page shown, store shown.
Try the landing page button and the in-app browser's "open in browser" option.
Re-test after major social app updates and before big campaigns. Add the results to your release testing notes.