Key takeaways
- The reason your Instagram, TikTok, or Facebook link "doesn't work" may not be a bug in your app — these apps use in-app browsers (IABs) that can suppress Universal Link / App Link handoffs.
- Keeping users inside the IAB supports retention and measurement. The result for you can be the same: a user who has your app installed lands on a mobile web view instead.
- The reliable pattern is a user-initiated tap-through handoff. A separate launch domain makes that pattern work on iOS; branded domains improve user trust, and QR codes cover desktop-to-mobile journeys.
- Nothing opens automatically in every IAB/version combination, so test the handoff in the exact social apps and OS versions your audience uses.
- The right architecture isn't "fight the IAB" — it's a managed link platform that updates its handoff logic as Meta and ByteDance ship updates.
The walled-garden crisis
In 2026, social is still the largest discovery surface for mobile apps. "Link in bio" on Instagram, "Shop Now" on TikTok, shared product links on WhatsApp — every brand depends on these clicks landing the user in the app.
But there's a structural obstacle: when a user clicks a link inside Instagram, TikTok, or Facebook, the platform doesn't hand the URL to Safari or Chrome. It loads the link inside its own internal browser — the in-app browser (IAB). And these IABs frequently block the OS-level intent calls that Universal Links and App Links rely on.
The user, who has your app right there on their home screen, ends up on a stripped-down mobile web view that doesn't recognize them as logged in. They abandon. Your conversion data shows a "successful click." Your funnel quietly leaks.
If your Instagram deep link isn't opening, this is almost certainly why.
Why Meta and TikTok block deep links (mostly)
It helps to understand the IAB's purpose. From the platform's perspective, the IAB serves two goals:
- Retention. Keep the user one swipe away from returning to the feed.
- Tracking. Inject scripts to observe what the user does on third-party sites.
Both goals are easier when the user stays inside the IAB instead of getting handed off to a native app. In practice, some IAB navigation paths suppress the OS handoff signals that would normally trigger your app.
The good news: the platforms haven't fully banned Universal Links. They've just made them more fragile and inconsistent. With the right link infrastructure, you can still get the handoff to fire — even from inside the IAB.
One reliable handoff, plus supporting fallbacks
Start with an "Open in App" intermediate page
The most common manual fix. Instead of pointing the link directly at a deep destination, you point it at a lightweight HTML page that says "Open in App" with a big tap target.
Why it works: a user-initiated tap on a button is a stronger trigger for OS handoff than an auto-redirect. The IABs are less likely to suppress an explicit user gesture.
Trade-off: an extra tap is friction, and friction costs conversion. Useful as a fallback, not as the only path.
Make the handoff reliable with a separate launch domain
This is the production-ready version of the intermediate-page pattern, and it is worth being precise about why the separate host matters.
On iOS these in-app browsers are WKWebViews, and a WKWebView honours a Universal Link only when the user taps a real link — a scripted redirect is ignored. There is a second trap: iOS suppresses Universal Links for navigation to the host you are already on, so an "Open App" button sitting on yourbrand.link/promo and pointing back at yourbrand.link/promo is inert no matter how the user reaches it.
Ulinkly serves the screen from a separate launch domain. Because the tap crosses hosts, iOS treats it as a genuine Universal Link activation and hands off to your app. The screen also offers a Download from App Store button for visitors who don't have the app. Across supported IABs, Ulinkly uses the user-tapped https://apps.apple.com URL first and retains the legacy itms:// form as a recovery attempt when it is available.
Why it works: it combines an explicit user gesture with a cross-host navigation, the path most likely to receive a valid OS handoff instead of relying on a scripted redirect.
Trade-off: the user taps. Automatic handoff is inconsistent across IAB and OS versions, so the dependable outcome is a dead end turned into one explicit tap.
For Ulinkly links this is on by default once your project's iOS app configuration is complete, since the Team ID and bundle identifier are what publish the association the button depends on.
Add a desktop-to-mobile QR fallback
Some campaigns get clicked on desktop — paid social rendered on a laptop, an email opened on a work computer — but the user's account and payment info are on their phone. The QR fallback Ulinkly renders bridges that gap: the desktop click produces a clean, branded QR. The user scans with their phone, the link resumes its mobile path, and the app opens.
This is less a workaround for the IAB and more a hygiene step for any link strategy that crosses devices.
Step-by-step: a working IAB-resilient setup
Step 1: configure a branded domain
In the Ulinkly dashboard, point a custom subdomain (links.yourbrand.com, go.yourbrand.com) at Ulinkly. A domain the user recognizes generally communicates more trust than an anonymous shortener and gives your team control over the hostname.
Step 2: complete the app-association configuration
Add the iOS Team ID and bundle identifier, plus the Android package name and SHA-256 fingerprint, to the Ulinkly project. Those identifiers are what let Ulinkly publish the AASA and assetlinks.json association files used by the launch-domain handoff. Ulinkly detects supported in-app browsers and presents the tap-through screen automatically; there is no separate "force open" toggle to enable.
Step 3: set per-channel social meta tags
A link with a generic preview gets fewer clicks. Ulinkly's social preview links let you control the OG image, title, and description, so the iMessage card, WhatsApp preview, and social card can look intentional. Pro tip: include an "Open in App" affordance in the OG image so users prime themselves for an app experience.
Step 4: test from inside the IAB
Don't trust simulators alone. Open Instagram on a real phone, share the link to your own DMs, and tap it from there. Repeat in TikTok, Messenger, and WhatsApp. The dashboard's recent-clicks log will show which path the OS actually took, which is what you want to confirm.
Influencer attribution in TikTok specifically
TikTok's IAB is one of the more aggressive ones, and TikTok is also the channel where attribution matters most for many brands. The combination is painful: high-value clicks routinely lose context.
The pattern that works is unique-per-creator Ulinkly links plus deferred deep linking:
- Each creator gets a unique link.
- A new fan clicks the link from inside TikTok and gets routed through the App Store (since they don't have your app yet).
- Ulinkly remembers which creator drove the click.
- After install, the user lands on the product the creator was promoting, and the install is attributed back to the creator — even if it happens hours after the click.
That pattern is the only way to honestly calculate creator ROI in a mobile-first world. (More on deferred deep linking.)
Why DIY breakouts decay
A common pattern: a team builds a redirect server that runs the OS handoff in JavaScript. It works. Three months later, Instagram ships a version that strips the redirect, conversions silently drop 18%, and nobody notices for a quarter.
The IAB-handoff problem is fundamentally a moving target. Meta and ByteDance update their browsers regularly, and the techniques that work today need to be re-validated continuously. A managed platform exists specifically because that monitoring is expensive to do well in-house. (Build vs. buy economics in detail.)
FAQ
Why does my Universal Link work in Safari but not from Instagram?
Safari uses the OS's full handoff stack. Instagram's IAB intercepts the click and tries to render it inside the IAB instead, often suppressing the OS handoff in the process. The link isn't broken — the IAB is filtering it.
Does this also affect WhatsApp and Messenger?
Yes, to varying degrees. Each app's IAB has its own quirks. WhatsApp tends to be more permissive than Instagram or TikTok, but it still benefits from the same handoff logic.
Will this fix my Universal Link inside the iOS Mail app?
The Mail app uses the OS's standard link handling, so Universal Links generally work there without special handling. The IAB problem is specific to social apps.
Can I just disable the IAB?
You can't, from the brand side — Meta and ByteDance control whether their IABs hand off to native apps. There's been pressure (regulatory and otherwise) to make IABs more transparent, but as of 2026 they remain the default.
What if my user has the app but isn't logged in?
Deep linking handles the routing; your app handles the auth. Most brands use deferred deep linking parameters to remember the original destination across the login flow, so the user lands on the right screen after authenticating.
Is this why my SMS links work better than my Instagram links?
Yes. SMS opens links via the OS handler, not an IAB. That's also why branded short links matter most over SMS — the link's CTR is bottlenecked by user trust, not by IAB filtering. (How branded short links lift SMS CTR.)
Stop losing social-driven users to the in-app browser. Create a free Ulinkly account and ship IAB-resilient links — or book a 20-minute audit and we'll review your highest-leverage social links together.