What Are Deep Links and Why They Matter

A few months ago I was sitting on my couch, scrolling through a friend's Instagram story, and she'd shared a link to a product on some clothing brand's website. I tapped it. And instead of opening the brand's app — which I definitely had installed — my phone opened Safari, loaded a janky mobile web version of the site, and then popped up one of those "Open in app?" banners that covered half the screen. I tapped that, and the app opened. To the homepage. Not the product. The homepage. So now I'm hunting through categories trying to find a pair of pants I'd already been looking at five seconds ago.

Key Takeaways

• The Basic Idea Behind Deep Linking
• How Instagram, Twitter/X, and Amazon Handle It
• The Three (or Four, or Five) Types of Deep Links
• The Messy State of Deep Linking in 2025
• Why Does Any of This Matter?
• The Web vs. App Tension

That experience? That's what happens when deep linking doesn't work. Or when it half-works. Or when nobody bothered to set it up at all. And honestly, it's still shockingly common in 2025.

Deep links are URLs that point to a specific location inside a mobile app rather than just a generic web page. That's the simplest definition. Instead of opening www.example.com in your browser, a deep link might open the Example app directly to a specific product page, a user profile, a conversation thread, or a particular piece of content. The "deep" part refers to the fact that you're going deeper than the app's front door. You're landing somewhere specific.

If that sounds straightforward, well, it is — conceptually. The implementation side is where everything falls apart.

The Basic Idea Behind Deep Linking

Think about how the web works. Every page has a URL. You click a link, your browser goes to that URL, and you see that page. Simple. Predictable. It's been working this way since the early 1990s. Tim Berners-Lee figured this out, and it just... worked. We cover this in more detail in App Deep Linking: A Developer's Guide.

Mobile apps broke that model. Apps are these walled-off little containers sitting on your phone. They don't have URLs in the traditional sense. Or at least they didn't. When mobile apps first became popular, there was no standardized way to say "open this app and go to this specific screen." You could open the app. That was about it. You'd land on whatever screen the developer decided was the default. If someone texted you "check out this cool thing on App X," you'd open App X and then try to find the cool thing yourself.

Deep linking was the answer to this problem, though it took years — and honestly, we're still figuring it out — for the technology to mature. The idea was: give app content addressable locations, just like web pages have URLs. Let a link point to a specific place inside an app. Let someone tap a link and land exactly where they should.

The earliest version of this was URL schemes. Custom URL schemes. You've probably seen these even if you didn't know what they were. Things like instagram://user?username=natgeo or twitter://status?id=12345. These are custom protocols — instead of http:// or https://, the app registers its own scheme, and when the operating system encounters a URL with that scheme, it hands it off to the corresponding app.

This worked. Sort of. The problem with URL schemes is that they're completely unregulated. Any app can claim any scheme. There's no verification, no central registry, no way to guarantee that myapp:// actually goes to the right app. Two apps could register the same scheme, and then it's just a coin flip which one opens. Also — and this is a big one — if the user doesn't have the app installed, a URL scheme just... fails. Nothing happens. Or you get an ugly error. There's no fallback to a web page, no graceful degradation. Just a dead end.

How Instagram, Twitter/X, and Amazon Handle It

Let's talk about real apps, because the theory only gets you so far.

Instagram is actually a decent example of deep linking done reasonably well, at least within its own walled garden. When you share an Instagram post link — something like https://www.instagram.com/p/ABC123/ — and the recipient has Instagram installed, tapping that link on most modern phones will open the Instagram app directly to that post. The app registers itself as the handler for instagram.com URLs. On iOS this uses Universal Links; on Android, it's Android App Links (formerly called verified deep links, because apparently nobody in this space can keep a name for more than two years).

But here's where it gets weird. If you tap that same Instagram link inside another app — say, inside Twitter's in-app browser — the behavior changes. Twitter's WebView might load the Instagram web page instead of opening the Instagram app. Some apps deliberately prevent other apps from intercepting their links because they want to keep you inside their own app. It's a mess. The user experience depends not just on whether deep linking is configured correctly, but on which app you're tapping the link from, which OS version you're running, and sometimes what the moon phase is. I'm only partly joking.

Twitter — or X, or whatever we're calling it this week — has its own deep linking situation. Links like https://x.com/username/status/12345 should open in the X app if it's installed. And they do. Most of the time.

On iOS, Apple's Universal Links system requires a specific JSON file (an apple-app-site-association file) to be hosted at a well-known path on the domain. If that file is misconfigured or if there's a CDN caching issue or if the user previously chose to open X links in Safari by long-pressing and selecting "Open in Safari" (which sets a persistent preference that most people don't know how to undo), then the link opens in the browser instead. I've seen people complain about this on forums for years. "Why won't Twitter links open in the app anymore?" Because you accidentally told iOS not to, and now you need to long-press a Twitter link and choose "Open in Twitter" to reset that preference. It's wildly unintuitive.

Amazon is perhaps the most interesting case because of the sheer complexity of their URL structure. Amazon product URLs are notoriously ugly and long, packed with tracking parameters, affiliate tags, and session information. Deep linking into the Amazon app means parsing all of that and landing the user on the correct product page, which Amazon does handle pretty well these days. But the path to get here was rocky.

For a long time, tapping an Amazon link on Android might open one of several Amazon apps — the main shopping app, Amazon Music, Kindle, or Prime Video — depending on URL patterns. And affiliate links added another layer of complication, since some affiliate redirect chains would break deep link detection entirely. The link would bounce through two or three redirect domains before reaching amazon.com, and by that point, the OS had lost track of where it was supposed to go. This ties directly into Deep Linking for Better Mobile User Experience, which is worth reading next.

The Three (or Four, or Five) Types of Deep Links

I mentioned URL schemes already. Those are sometimes called "traditional deep links" or "classic deep links." They were first. They're simple. They break easily. They require the app to be installed.

Then there are deferred deep links. The "deferred" part means the link works even if the app isn't installed yet. Here's the flow: user taps a link, the app isn't installed, so they get sent to the App Store or Google Play to download it. After they install and open the app for the first time, the app somehow "remembers" the original link and takes them to the intended content. That "somehow" is doing a lot of heavy lifting in that sentence. Different deep linking providers handle it differently — some use device fingerprinting, some use clipboard tricks, some use the OS's built-in referrer mechanisms. None of them are 100% reliable. But when it works, it's kind of magic. You tap a link to a specific product, install the app, open it, and you're looking at that product. No searching around.

Universal Links (iOS) and Android App Links are the modern, platform-sanctioned approach. These use standard HTTPS URLs — the same URLs that work on the web — and add a layer on top where the app can claim ownership of certain URL patterns. When you tap a Universal Link on iOS, the OS checks whether any installed app has claimed that URL pattern. If yes, it opens the app. If not, it opens the URL in Safari. This is way better than URL schemes because there's always a fallback, there's a verification mechanism (the app developer has to prove they own the domain), and the URLs look like normal web URLs instead of weird custom protocols.

But Universal Links have their own quirks. They don't work if the user types the URL into Safari's address bar — only if they tap a link. They don't work in all contexts (JavaScript redirects to Universal Links don't always trigger the app). And the apple-app-site-association file, which is the configuration file that tells iOS which URL patterns map to which app, gets cached by iOS in ways that are sometimes hard to debug. I've seen developers make changes to that file and then wait days for iOS to pick up the new version.

Contextual deep links are another thing you'll hear about. These are deep links that carry additional metadata — not just "open this screen in the app" but also "and here's some context about who sent the link, what campaign it's from, and what the user was doing before they tapped it." Marketing teams love contextual deep links because they enable attribution and personalization. A user taps a deep link from a promotional email, the app opens to the right screen, and the app also knows this user came from that specific email campaign. This is more of a marketing and analytics concept than a technical one, but it gets lumped into the deep linking conversation constantly.

The Messy State of Deep Linking in 2025

Alright. I want to spend some real time on this because I think it's the most important part and it doesn't get talked about honestly enough.

Deep linking is, in 2025, still a disaster. Maybe not a total disaster. Maybe "ongoing controlled chaos" is more accurate. The technology works when everything is configured correctly, the stars align, and nobody has done anything unexpected. But the number of things that can go wrong is staggering.

Let's start with fragmentation. iOS and Android handle deep linking differently. Not slightly differently. Radically differently, in terms of the underlying mechanisms, the configuration requirements, the fallback behaviors, and the edge cases. If you're building a cross-platform app, you're essentially implementing deep linking twice, with different configuration files, different verification processes, and different debugging tools. And then you have to test on both platforms across multiple OS versions, because behavior changes between iOS 16 and iOS 17 are not trivial, and Android's handling of App Links has evolved significantly across different versions too. To understand this better, take a look at Universal Links vs App Links: iOS and Android Comparison.

The in-app browser problem is perhaps the most persistent headache. When a user taps a link inside Facebook, Twitter/X, LinkedIn, TikTok, or any app that has its own built-in browser (which is most social media apps), the link often opens in that app's WebView instead of triggering a deep link to the external app. This is partly by design — social media platforms want to keep users inside their app — and partly because WebViews don't support Universal Links or App Links the same way the system browser does. There are workarounds. You can use redirect pages that detect the WebView environment and try to force-open the native app using various tricks. But these workarounds are fragile, platform-specific, and break whenever the host app updates its WebView behavior.

I should note that this isn't entirely the social platforms' fault. Apple and Google haven't exactly made it easy for WebViews to support deep linking consistently. The technical specifications exist, but implementation is spotty and the behavior varies depending on the WebView version, the host app's configuration, and other factors that nobody outside of Apple and Google fully understands.

Then there's the attribution problem. When a user taps a deep link, how do you know where they came from? How do you connect the tap to a marketing campaign, a referral, or a specific piece of content? This used to be handled primarily through device fingerprinting — matching characteristics of the device that tapped the link with the device that opened the app. But Apple's App Tracking Transparency (ATT) framework, introduced with iOS 14.5, threw a wrench into that approach. Fingerprinting is now technically against Apple's policies (though enforcement has been inconsistent), and the IDFA (Identifier for Advertisers) requires explicit user consent, which most users decline. On Android, Google has announced similar privacy restrictions with the deprecation of the advertising ID for certain use cases. Attribution is getting harder, and deep linking providers are scrambling to find privacy-compliant alternatives.

The deferred deep linking problem has gotten worse too, not better. Clipboard-based approaches — where the link URL is copied to the clipboard and the app reads it on first launch — are now blocked or restricted on both iOS and Android. iOS shows a paste permission dialog, which is confusing to users who didn't knowingly copy anything. Android has introduced similar restrictions. Device fingerprinting, as mentioned, is increasingly problematic. Some deep linking providers have moved to probabilistic matching with reduced accuracy, which means deferred deep links fail more often than they used to. That magical "install the app and land on the right content" experience? It works maybe 60-70% of the time now, depending on the platform and the provider. Maybe less.

There's a company called Branch (branch.io) that has become sort of the default deep linking provider for a lot of apps. They handle a ton of the complexity — the cross-platform configuration, the fallback logic, the attribution, the deferred deep linking. But even Branch's documentation acknowledges how many edge cases and failure modes exist. Their troubleshooting guides are enormous. I spent an afternoon reading through their support forum once and came away with a profound respect for their engineering team and also a deep sense of existential dread about the state of mobile linking.

AppsFlyer is another major player, especially in the marketing attribution space. Their OneLink product handles deep linking alongside attribution, and they've invested heavily in privacy-compliant approaches as the tracking situation shifts. But the same fundamental problems apply — too many variables, too many platform differences, too many places where things can silently break.

Firebase Dynamic Links was Google's attempt at a deep linking solution, and in 2023 Google announced they were shutting it down. Just... discontinuing it. This left a lot of developers who had integrated Dynamic Links into their apps scrambling for alternatives. Google pointed them toward App Links and custom solutions, but the fact that even Google couldn't make their deep linking product work well enough to justify maintaining it tells you something about how difficult this problem space is.

Why Does Any of This Matter?

Fair question. If deep linking is so broken and complicated, why bother?

Because the alternative is worse. Without deep linking, every shared link to app content dumps the user on a web page or an app homepage. Every QR code that's supposed to take you somewhere specific takes you somewhere generic. Every marketing email that links to a product opens a browser instead of the app where the user already has their payment info saved. Every notification that should deep link to a conversation thread opens the app's main screen instead. This is closely related to what we cover in Understanding Affiliate Links: A Beginner Guide.

The friction isn't abstract. It's measurable. Studies from Branch and others have shown that deep links can increase conversion rates by 2-3x compared to links that don't deep link. That makes intuitive sense. If tapping a link takes you directly to the thing you wanted to see, you're more likely to take action on it than if you have to hunt for it yourself. In e-commerce, the difference between landing on the product page versus landing on the homepage is enormous. In social apps, the difference between landing on the shared content versus landing on a feed is the difference between engagement and abandonment.

Retention is affected too. Apps that use deferred deep linking — where new users land on specific content after install rather than a generic onboarding flow — report higher day-1 and day-7 retention rates. The user's first experience with the app is the thing they were actually interested in, not a cold start. That matters.

And it's not just consumer apps. Enterprise apps, B2B tools, productivity software — they all benefit from deep linking. Imagine getting a Slack notification about a specific message and tapping it only to land on your Slack workspace's general channel. That would be maddening. Slack's deep linking works well (usually), and that's a big part of why the notification experience feels smooth.

The Web vs. App Tension

There's a philosophical tension here that I find interesting. The web was built on the idea that everything is linkable. Every resource has a URL. Anyone can link to anything. It's open, it's interoperable, it's beautiful in its simplicity. Apps took a different path. Apps are closed by default. They're walled gardens. Deep linking is, in a way, an attempt to graft the web's openness onto the app model. To make apps behave a little more like the web.

Some people argue that Progressive Web Apps (PWAs) are the real answer — make everything a web app, and the deep linking problem disappears because everything already has a URL. And there's something to that argument. PWAs have gotten significantly better over the years. They can work offline, they can send push notifications (on Android at least; iOS support arrived late and is still limited), they can feel very app-like. But they still can't do everything native apps can do, and the business incentives around app stores (discoverability, monetization, the perceived legitimacy of having "an app") mean that native apps aren't going anywhere soon.

So we're stuck in this in-between world where content exists both on the web and in apps, and deep linking is the bridge between them. It's an imperfect bridge. A rickety one, sometimes. But it's what we have.

Where Is This Going?

I genuinely don't know. And I'm suspicious of anyone who claims to know with certainty.

Apple and Google could fix a lot of the fragmentation by improving their platform support for deep linking, making Universal Links and App Links more reliable, better documented, and more consistent across contexts. They could require WebViews to properly support deep linking. They could provide better debugging tools. Whether they will is another question. Both companies have incentives that sometimes conflict with making cross-app linking work smoothly. Apple wants you in the Apple world. Google wants you on the web (where their ads are). Neither is fully incentivized to make it dead simple to link from one third-party app to another. For a deeper look at this topic, see our guide on 301 vs 302 Redirects: Impact on Link Equity.

The privacy situation will continue to make attribution-based deep linking harder. That seems inevitable. The era of freely tracking users across apps and websites is ending, and deep linking solutions that relied on tracking capabilities will have to adapt. What replaces device fingerprinting and advertising IDs? Some kind of privacy-preserving attribution framework, probably. Apple's SKAdNetwork and Google's Privacy Sandbox are early attempts, but they're designed more for ad attribution than deep linking specifically.

Maybe AI assistants and chat-based interfaces will change the equation entirely. If users increasingly interact with apps through Siri, Google Assistant, or ChatGPT-style interfaces, the concept of "tapping a link" might become less central. Instead of sharing a link, you'd share an intent: "show me the product Sarah mentioned." The assistant would figure out which app to open and which screen to display. That's speculative, obviously. But the trajectory seems plausible.

For now, deep linking remains one of those things that's easy to explain and really hard to get right. It's a simple idea — links that go to specific places inside apps — that's been complicated by platform fragmentation, privacy regulations, business incentives, and the fundamental tension between the open web and closed app environments. If you've ever tapped a link and ended up somewhere you didn't expect, you've experienced the gap between what deep linking promises and what it actually delivers. That gap is narrowing, slowly, unevenly. But it's still there. And if you're building anything that involves sharing links to app content, you're going to be dealing with it whether you want to or not.