Deep Link Reference
What actually opens each app on iOS and Android — including the cases where the obvious answer is wrong.
Every row below is asserted against the code that generates the links on this site. A test runs each sample URL through the real scheme builders and fails the build if the documentation and the behaviour disagree, so this page cannot quietly drift out of date. It is deliberately not a list of a hundred apps — an unverified scheme sends users to an “invalid address” alert, which is worse than no entry at all.
Android — one mechanism, no per-app list
Every link uses a package-less intent:// with S.browser_fallback_url set. Android hands it to whichever app has verified that domain through assetlinks.json, and falls back to the default browser when no app claims it. Nothing is pinned, so a missing or region-mismatched app never dead-ends. The single exception is Flipkart, which is pinned to com.flipkart.android because the pin still opens the app on devices where App Links verification failed — notably the fkrt.cc short hosts.
iOS — three different paths depending on context
Apple has no equivalent of intent://, and Universal Links are suppressed inside in-app webviews. So the behaviour branches: in real Safari a plain https URL opens the app via its Universal Link; inside an in-app webview with a known custom scheme, the scheme is used with a timed https fallback; inside an in-app webview with no known scheme, the link escapes to real Safari with x-safari-https:// (iOS 17+) and lets the destination take over from there.
Why custom schemes are a short list on purpose
A custom scheme that is not registered on the device produces an 'invalid address' alert and a bounce to the browser — strictly worse than not trying. So a scheme is only used when it is known to be registered and can be built reliably from the URL. Five platforms qualify. Everything else takes the Safari-escape path, which degrades to simply loading the page.
Per-platform behaviour
| Platform | Hosts | iOS scheme | Notes |
|---|---|---|---|
| YouTube | youtube.com, youtu.be | vnd.youtube://<videoId> | youtube:// does NOT work — the iOS app registers vnd.youtube://. Shorts ids are ordinary video ids, so /shorts/ URLs open in-app through the same scheme. |
| YouTube Music | music.youtube.com | none — Safari escape | Deliberately excluded from the YouTube scheme: vnd.youtube:// would open the video in the main YouTube app instead of YouTube Music. No documented YT Music scheme exists, so these take the Safari-escape path where the Universal Link opens the right app. |
| Spotify | open.spotify.com | spotify://<type>/<id> | Covers track, album, artist, playlist, show and episode — the content type is read straight out of the URL path, so all six work through one builder. |
| Telegram | t.me, telegram.me | tg://resolve?domain= or tg://join?invite= | Two different schemes: public t.me/<name> maps to tg://resolve, private t.me/+<invite> maps to tg://join. Using resolve for an invite link silently fails. |
| wa.me, chat.whatsapp.com, api.whatsapp.com | whatsapp://send?phone= or whatsapp://chat?code= | Chat links carry a phone number, group invites carry a code, and they use different schemes. This also skips WhatsApp's 'Continue to chat' interstitial, which is where a slice of leads is normally lost. | |
| Medium | medium.com | medium://p/<postId> | The post id is the trailing hex segment of the slug. Articles on custom publication domains have no id to extract, so those fall back to the Safari-escape path. |
| instagram.com | none — https self-bounces | No custom scheme needed: instagram.com hands off from plain https to its own app even inside another app's webview. Forcing a scheme here would be strictly worse than doing nothing. | |
| X (Twitter) | x.com, twitter.com | none — https self-bounces | Self-bouncing from https. Both the x.com and legacy twitter.com hosts behave the same way. |
| TikTok | tiktok.com, vm.tiktok.com | none — https self-bounces | Self-bouncing from https, including the vm.tiktok.com short host. |
| facebook.com, fb.watch | none — https self-bounces | Self-bouncing from https. Meta's own webviews are the most common origin for these links. | |
| linkedin.com | none — https self-bounces | Self-bouncing from https, for both /in/ profiles and /posts/ URLs. | |
| Amazon | amazon.*, amzn.to, amzn.in, a.co | none — Safari escape | No scheme and no pinned Android package, deliberately. Amazon ships per-region apps (com.amazon.Amazon, com.amazon.AmazonIN, in.amazon.mShop.android.shopping, …) so any pinned identifier is unresolvable in every other region. The published assetlinks.json lists all regional packages, so a package-less intent resolves correctly wherever the user is. Product URLs are also reduced to the bare /dp/<ASIN> form, because Amazon's AASA whitelists that shape and excludes various ref= patterns. |
| Flipkart | flipkart.com, fkrt.cc, fkrt.it, dl.flipkart.com | none — Safari escape | The one pinned Android package on the site (com.flipkart.android). Flipkart ships a single worldwide package, and the pin still opens the app on devices where App Links verification failed — which is the normal case for the fkrt.cc short hosts. |
| reddit.com, redd.it | none — Safari escape | Package-less intent on Android, Safari escape on iOS. No custom scheme is built. | |
| OnlyFans | onlyfans.com | none — Safari escape | Safari-escape path on iOS. Highest click-through page on this site at 27.4%, which is a statement about search intent rather than about deep linking. |
| pinterest.com, pin.it | none — Safari escape | Package-less intent on Android; Safari escape on iOS where Pinterest's Universal Link takes over. | |
| Snapchat | snapchat.com | none — Safari escape | Snapchat is detected as an in-app webview when links arrive FROM it, but its own links take the ordinary intent / Safari-escape path. |
| Twitch | twitch.tv | none — Safari escape | Package-less intent on Android; Safari escape on iOS. Channels, VODs and clips all behave identically. |
| Discord | discord.gg, discord.com | none — Safari escape | Invite links resolve to the join screen once the app opens. Safari escape on iOS. |
| SoundCloud | soundcloud.com, on.soundcloud.com | none — Safari escape | Package-less intent on Android; Safari escape on iOS. |
| Google Maps | google.com/maps, maps.app.goo.gl | none — Safari escape | The Share button produces a maps.app.goo.gl short link, which the Maps app claims through App Links on Android. |
| Threads | threads.net, threads.com | none — Safari escape | Not on the self-bouncing list despite being Meta's — it is newer than that list. On iOS it is still caught by the in-app-webview check, because iOS webviews embedded by other apps omit the Safari token from the user agent, so it takes the Safari-escape path. |
| Myntra | myntra.com | none — Safari escape | Package-less intent on Android; Safari escape on iOS. |
| eBay | ebay.com and regional domains | none — Safari escape | Regional domains (ebay.co.uk, ebay.de, …) each verify their own host, so the package-less intent resolves correctly per region. |
| Anything else | any https URL | none — Safari escape | There is no allowlist. Any https URL gets a package-less Android intent with a browser fallback, and the Safari-escape path on iOS. If the destination has an app that verified its domain, it opens; if not, the browser does. That is the whole design. |
Short-link hosts that must be expanded first
These hosts cannot open an app themselves — they only redirect. The real destination has to be resolved server-side before any of the behaviour above applies, otherwise the intent targets the shortener and lands in a browser.
- amzn.to
- amzn.in
- amzn.eu
- amzn.asia
- a.co
- fkrt.cc
- fkrt.it
- fkrt.co
- dl.flipkart.com
The three mistakes that cost the most time
- 1Using youtube:// on iOS. The app registers vnd.youtube:// — the obvious guess silently does nothing.
- 2Pinning an Android package for Amazon. Amazon ships a different package per region, so any pin is unresolvable everywhere else and Chrome quietly opens the browser fallback instead.
- 3Assuming Universal Links work everywhere on iOS. They are suppressed inside in-app webviews, which is exactly where your links get tapped.