How to create a deep link (that actually opens the app)

Someone taps your link expecting to land inside your app. Instead they get a login wall in a browser they didn't choose, half their session gone, autofill dead. They bounce, and you never hear from them again.

That gap — between "I have an app" and "my link opens it" — is what a deep link closes. The annoying part is that writing one is genuinely easy; you can hand-craft a working deep link in the next two minutes. People still get this wrong because of everything that happens after the link leaves your hands: the app isn’t installed, the browser is Instagram’s, the phone is an iPhone that quietly ignores the thing you just built. So let’s do both halves — the easy one, then the one that matters.

A normal link points at a web address. A deep link points at a place inside an app — a product, a chat thread, one specific playlist. Same idea as a URL that jumps to #pricing halfway down a page, except the "page" is a native screen.

There are two ways to express that under the hood, and the difference decides whether your link works or dies without a sound.

Custom schemes are the ones every tutorial reaches for because they’re trivial. Universal Links (iOS) and App Links (Android) are the ones that hold up in the wild, because the operating system trusts them — they’re just https URLs your app has claimed.

Say your app registered the scheme myapp. A deep link to product 42 is literally myapp://product/42. That's the whole thing. The path after the :// is yours to design — the app reads it and routes to the right screen.

To test it without shipping anything: on Android, run adb shell am start -a android.intent.action.VIEW -d "myapp://product/42" to fire it at the device. On iOS, paste the scheme into Safari’s address bar, or drop it in a Note and tap it. If your app pops open on the right screen, the plumbing works.

And now you have a deep link that works flawlessly on your own phone — which is exactly the trap.

Your link will land on phones that don't have your app. When a custom scheme like myapp:// hits a phone with no myapp installed, nothing catches it — the user gets an error or just a blank nothing. For anything public, that isn't an edge case; it's most of your traffic.

So a real deep link is never one link. It's a decision: app here, open it; app missing, send them to the store or the mobile site. You can't express that in a raw myapp:// string. You need something in the middle that checks and routes.

This is also where Universal Links earn their keep. Because they’re https, a missing app just loads the web page at that same URL — no dead end. The price is setup: you host an apple-app-site-association file (iOS) or assetlinks.json (Android) on your domain, list your app IDs, and the OS verifies you actually own both ends. Fiddly, but that verification is the entire reason the link is trusted.

Here's the one that ruins people's afternoon. Tap a link inside Instagram and it doesn't open your phone's real browser — it opens Instagram's own in-app browser, a stripped-down webview living inside the app. Those webviews are hostile to deep links. iOS especially won't honor a custom myapp:// scheme fired from inside another app's webview. So the exact link you tested and watched work on your desk does nothing for the person tapping it from a Reel.

There are workarounds — a tappable https intermediary, an intent:// URL on Android, a landing page with a real "open in browser" escape hatch — but stacking them per platform, per app, per iOS version is a genuine time sink. It’s the reason "deep linking" is a product category and not a one-line snippet.

If you're building the app and want deep links as a feature, set up Universal Links and App Links properly. It's the correct foundation and it's worth the afternoon.

If you just want a link that opens the right native app for your audience — an Instagram link, a YouTube link, your own store — without touching an SDK or hosting association files, that's the narrow problem directinapp solves. You paste the destination, it hands back a short link, and the redirect layer works out whether to fire the app's scheme, fall through to the store, or drop to the mobile site — including the ugly in-app-browser cases. No SDK, no code inside your app. It can't install an app that isn't there (nothing can), but it stops sending people to the logged-out-browser dead end.

Either way, keep the one rule people skip: a deep link is a plan for two outcomes, not a single URL. Build the fallback first and everything after it hurts less.