Deep Links: Open Short Links in Native Apps

You publish a YouTube video. You share the link in your newsletter, in a Slack community, in your podcast show notes. A subscriber taps the link on their phone. They expect the YouTube app to open. Instead, a stripped-down mobile web page loads in Safari or Chrome, no recommendations sidebar, no comments tied to their account, no native playback controls, no easy way to subscribe. If you used Firebase Dynamic Links for this before Google shut it down, our Firebase Dynamic Links migration guide maps every capability to a replacement.

The subscriber bounces. You lose the engagement signal YouTube's algorithm needs to recommend your video. The same story plays out for every Spotify playlist link, every Instagram profile share, every TikTok creator URL, the mobile web is consistently worse than the native app, and yet the mobile web is what users get by default when they tap a short link.

Why this happens

Short links are HTTP URLs. When a mobile browser receives a 302 redirect from flyn.to/q2-launch to https://www.youtube.com/watch?v=..., it follows the redirect inside the browser. The OS doesn't know the YouTube app could have handled this URL. The browser stays in front. The user shrugs and watches in the worst possible context.

What you lose every day this stays broken

• Session length: native app sessions are 2-4x longer than mobile web on every major platform
• Conversion events: subscribes, follows, likes, saves, comments, all higher in-app
• Repeat visits: once a user opens your content in the native app, the app is also in their recent-apps switcher; web pages aren't
• Algorithm signal: every platform's ranking model weights native engagement heavier than web engagement

If you're sharing links to content on YouTube, Instagram, TikTok, or Spotify and they're not deep-linked, you're leaving real attention on the table. The fix is a single toggle.

A deep link is a URL that, when opened on a mobile device, launches the native app for the destination and navigates to a specific screen, not the app's home screen, but the exact piece of content. Tap a deep link to a TikTok video and the TikTok app opens directly on that video.

Under the hood, deep links use platform-specific routing mechanisms. iOS and Android handle them differently.

iOS: Universal Links and URI schemes

Apple's preferred mechanism is the universal link, a plain HTTPS URL that the OS knows belongs to a registered app. Apps declare which domains they handle via an apple-app-site-association file, and when the user taps a matching URL, iOS opens the app instead of the browser. YouTube, Instagram, Spotify, and every other major app does this.

The older mechanism is the custom URI scheme: youtube://www.youtube.com/watch?v=abc, instagram://user?username=jane, spotify://track/.... These work but only fire if the app is installed; if it isn't, the browser shows an error. They're still useful as fallbacks, but universal links are the modern default.

Android: Intent URLs

Android uses intent URLs, a special URL format that encodes both the target app package and a fallback URL: intent://www.youtube.com/watch?v=abc#Intent;package=com.google.android.youtube;S.browser_fallback_url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Dabc;end. If the YouTube app is installed, it opens. If not, the browser navigates to the fallback URL automatically.

How Flyn unifies both

Writing the right URI scheme by hand for 18 platforms across two operating systems is the kind of busy work nobody should do. Flyn does it for you. When you enable Deep Links on a short link, Flyn's redirect server inspects the User-Agent, picks the correct routing strategy for the device, and serves the right HTML or URL. You toggle a switch.

Flyn ships with first-class deep-link routing for 18 platforms: every app in the table below, plus App Store links on iOS and Google Play links on Android, which open the store app. Each one has its own URI scheme handling, fallback behavior, and platform quirks, but you don't need to know any of them.

The full list

Need a platform that isn't listed? Email the team, most new platforms ship within a release cycle. The same redirect engine that powers the listed platforms is fully data-driven, so adding a new one is a config change, not a code release.

Platform-shortener pairing

Every Flyn short link can deep-link, but the experience is sharpest when you combine deep linking with a platform-specific shortener. The Spotify shortener, for instance, pre-validates that your destination is a real Spotify URL before creating the link, so the deep-link redirect never fails silently. Same for the YouTube shortener and the Instagram shortener.

From a Flyn user's perspective, deep linking is one toggle. From the implementation side, iOS and Android behave differently in ways that occasionally surface to the user. Understanding the differences helps you debug edge cases.

The behavior matrix

The in-app browser problem

The single most common deep-link complaint is: "I tapped the link inside Instagram and it didn't open the YouTube app, it opened YouTube in Instagram's in-app browser." This isn't a Flyn bug; it's Instagram's in-app browser intercepting the link. On iPhone, social in-app browsers, Meta's in particular, also block the automatic app handoff that works in Safari, so a page that tries to open the app on its own can fail without a word.

The mitigation: on iPhone, Flyn detects the Instagram, Facebook, Messenger, TikTok, Snapchat, LINE and LinkedIn in-app browsers by User-Agent and serves an escape page instead of the automatic handoff. The page names the app (for example, "Open in YouTube") and shows one button that opens it, because a real tap has the best chance of reaching the app; an App Store link is also tried once on its own. If the visitor is still on the page about 2 seconds later, it adds that in-app browser's menu step out to the system browser (inside Instagram: the three dots at the top right, then "Open in external browser") and an "Open the website instead" link. On Android, in-app browsers get the same page as any Android browser, which tries the app's intent URL and moves to the web URL after about 2 seconds. Once the link is open in the system browser, the standard deep-link page runs.

iPad and tablet handling

Deep links sort a request by the user agent the browser sends, not by the shape of the device. The deep-link step serves its native-app page only to a request whose user agent names an iPhone, iPad, iPod or Android device, and it reads a Mac-like user agent as desktop. Safari on iPad usually presents a Mac-like user agent, because it asks for the desktop version of websites by default, and Android tablets set to request desktop sites can send a desktop user agent too. On a link with a Mac URL, Flyn first checks whether a Safari visitor is on a Mac or an iPad, with a blank device check page, and then routes the click. Why Safari on iPad reports itself as a Mac, and how to test it, is in iPad Safari says it is a Mac.

The 2-second fallback timer

Flyn's redirect page tries the app as soon as it loads and starts a 2-second JavaScript timer. If the app opens, the page loses focus and the timer does nothing. If the page is still in front when the timer fires, it redirects to the web URL, and if the page has not moved to the web URL by 3 seconds, an "Open in browser instead" link appears. Two seconds is meant to give the OS time to launch the app while keeping the wait short for a visitor without it. To route the same link by country as well as device, see our guide to geo-targeting links by country.

Two ways, dashboard or API.

From the dashboard

Create or edit any short link. Open the Routing tab. Toggle Open in native app on. Save. That's the whole flow. You don't pick a platform, Flyn auto-detects the destination URL and applies the matching routing strategy.

From the API

Set deep_link: true in the body of POST /api/links:

• Required fields: destination (the long URL to a supported platform)
• Add deep_link: true to enable native-app routing
• Combine with any other field, slug, tags, password, expires_at, UTM parameters

See the deep links API doc for the full field reference and the API guide for authentication and rate limits. Same flag applies to PATCH /api/links/:id if you're retrofitting deep linking onto existing short links.

From the Chrome extension

The Flyn Chrome extension lets you shorten any URL in one click from your browser toolbar. Deep linking is an advanced option in the extension's settings, toggle it on and every link the extension creates is deep-linked by default. Handy for content creators who share dozens of platform URLs per day.

When a request hits a deep-linked Flyn short link, the redirect server runs a five-step decision tree. Understanding it makes debugging trivial.

Step 1: User-Agent classification

The server parses the User-Agent header and classifies the request as iOS, Android, or desktop, and separately flags in-app browsers (Instagram, Facebook, Messenger, TikTok, Snapchat, LINE and LinkedIn) and crawlers (Twitterbot, facebookexternalhit, LinkedInBot, Googlebot, etc.).

Step 2: Crawler short-circuit

If the request is from a crawler, the server returns a plain 302 Found to the destination URL. This ensures social link previews, Open Graph tags, and SEO crawlers see the canonical destination, exactly the same content they'd see for a non-deep-linked short link. Verify with the Open Graph checker if you're paranoid.

Step 3: Desktop short-circuit

Desktop browsers skip the native-app step and usually get a plain 302 to the web URL. There's no native app to route to on macOS or Windows, opening the link in Chrome or Safari is the right behavior. If the link also has a Windows or Mac URL on the Routing tab, desktop visitors on that system are sent there instead, because device rules run before the deep-link step. On a link with a Mac URL, Safari on a Mac or an iPad first gets a blank device check page, then continues (with JavaScript off it continues as a Mac), while Chrome, Edge and Firefox on a Mac go straight to the Mac URL.

Step 4: Mobile routing

For mobile visitors, apart from the iPhone in-app browser taps in Step 5, the server returns a lightweight HTML page with inline CSS and JavaScript. The page:

• Sends the browser to the app as soon as it loads: the URI scheme on iPhone (for a YouTube video, vnd.youtube://) or the intent:// URL on Android
• Starts a 2-second setTimeout that redirects to the web URL if the page is still in front
• Shows an "Open in browser instead" link after 3 seconds if the page has not moved to the web URL by then
• Shows an "Opening in app..." spinner so users who do see the page briefly understand what's happening

Step 5: In-app browser escape page on iPhone

If the request comes from an iPhone and the User-Agent matches the Instagram, Facebook, Messenger, TikTok, Snapchat, LINE or LinkedIn in-app browser, the server skips the automatic handoff, which those browsers block, and returns an escape page: a button named for the app, such as "Open in YouTube", then, if the visitor is still there about 2 seconds later, that in-app browser's menu step out to the system browser and an "Open the website instead" link. Android in-app browsers get the Step 4 page.

The best deep-link implementation is the one users never notice. If your subscriber taps a link in Slack and the YouTube app opens to your video, that's the goal. No "did this work?" moment, no fallback page, no spinner. Just the native app, ready to play.

Deep linking composes with everything else Flyn does. The redirect engine evaluates features in a deterministic order, so there's no surprise interaction.

The evaluation order

1. Expiration check, if expires_at has passed, the user sees the "link expired" page (a crawler gets a 410 Gone); otherwise, continue
2. Click limit, once a link has reached its cap, later clicks go to its fallback URL, or to a "no longer available" page if it has none
3. Password gate, if a password is set, the user sees the prompt; after the right password Flyn sends them to the main destination, so device and country rules, the A/B split and deep linking do not run on a password-protected link
4. Crawler check, known crawlers skip the routing, A/B and deep-link steps below and are not counted as clicks (see click fraud prevention)
5. Device rules, an iOS, Android, Windows or Mac URL set on the Routing tab is picked first
6. Country rules, checked only when no device rule matched
7. A/B testing splits, applied only when no device or country rule matched, picking one of the link's destinations by weight
8. Deep link routing, the destination chosen above feeds into the deep-link logic described above

Analytics behavior

Every click on a deep-linked short link is recorded in Flyn analytics with the same fidelity as any other click: geo, device, OS, browser, referrer, UTM. On Pro, the operating system and referrer breakdowns show which clicks came from iOS or Android and which sites referred them, a signal of where the link is being shared. Flyn records the click when it serves the page, and your analytics do not show whether the app opened.

Custom OG previews still work

Because crawlers get a plain redirect, your destination URL's Open Graph tags (title, description, image) are what social platforms render in preview cards. The deep-link redirect is invisible to them. If you want to validate that your previews look right, run the destination URL through the Open Graph checker. It tests the exact response Facebook, Twitter, and LinkedIn see.

Deep linking helps whenever your destination is a piece of content on a platform with a strong native app. It doesn't help when there's no app, the app is poorly maintained, or the destination is a marketing landing page that lives only on the web.

Strong candidates for deep linking

• Newsletter links to YouTube videos, subscriber bases tap from email apps on mobile
• Podcast show-note links, listeners on iPhones expect Apple Podcasts, Spotify to open
• Bio links, Linktree alternatives benefit massively from native-app open
• Social media cross-posts, tweet a TikTok link, deep-link it so the TikTok app opens
• Discord invites and Telegram channel links, almost always tapped on mobile
• WhatsApp Business catalog links, see the catalog strategy guide

When deep linking doesn't apply

• Marketing landing pages, your own website has no native app; web is the destination
• Generic example.com URLs, only platforms with registered apps benefit
• Internal corporate links, your team's SharePoint or Notion doesn't need to open natively
• Print QR codes, fine to deep-link these, but the user is already opening via camera, so the UX win is smaller

How to measure the win

Enable deep linking on a representative set of links for one week. Compare the click-through-to-conversion rate (subscribes, follows, saves, plays) against the same set during the previous week without deep linking. Native-app destinations almost always show a 20-50% lift in downstream engagement. That's a free, no-code win, and it's the reason most teams turn deep linking on once and never look back.

A pragmatic enablement rollout

If you manage hundreds of existing short links, don't enable deep linking on everything at once, instead, enable it on the 10 highest-traffic links pointing to YouTube, Instagram, and Spotify. Watch a week of analytics. If engagement rises (it will), scripts the rollout: a tiny script that lists all your links via GET /api/links, filters by destination domain, and PATCHes deep_link: true. See the API guide for the rate-limit pattern.

Deep linking is sending someone to a specific place inside an app instead of to a website or the app's home screen. A normal link opens a browser. A deep link opens the YouTube app on the exact video, the Instagram app on the right profile, or your own app on the screen the user expected. The "deep" part means it reaches a precise destination, not just the front door.

The three flavors

• URI scheme links such as instagram://user?username=flynlinks: the oldest method, fast but they fail silently when the app is not installed.
• Universal Links (iOS) and App Links (Android): standard https:// URLs the operating system routes into the app when it is installed, and to the web when it is not. The modern default.
• Deferred deep linking: the intended destination survives an app install, so a brand-new user still lands on the right screen after downloading.

You do not have to hand-write any of this. Build one with the deep link generator, confirm exactly where it lands with the deep link tester, and see the routing details in the deep links docs.