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 16+ 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 16+ platforms. 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. Most major social apps do the same on both iOS and Android, and there's no reliable client-side workaround.

The mitigation: Flyn detects the in-app browser via User-Agent and serves the plain web URL directly, so users at least get the mobile web experience instead of a confusing redirect chain. When the user later opens the same link in a real browser (e.g. by tapping "open in Safari" from Instagram's menu), the deep-link logic kicks in normally.

iPad and tablet handling

iPad and Android tablets count as mobile devices for routing purposes. Universal links work on iPad if the iPad version of the app is installed. Some apps (like Instagram) don't ship an iPad-native build, so the universal-link miss falls back to the web URL. Again, no client-side workaround, but the fallback is graceful.

The 1.5-second fallback timer

For platforms using URI schemes (rather than universal links), Flyn's redirect page tries the URI scheme immediately and starts a 1.5-second JavaScript timer. If the app opens, the user is taken there and the timer never fires. If the app isn't installed, the timer redirects to the web URL. 1.5 seconds is long enough that the OS has time to launch the app even on a slow device, but short enough that an uninstalled-app user doesn't feel the wait. 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 one of: iOS mobile, iPadOS, Android mobile, Android tablet, desktop browser, in-app browser (Instagram, Facebook, LinkedIn, TikTok), or crawler (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 get a plain 302 too. There's no native app to route to on macOS or Windows, opening the link in Chrome or Safari is the right behavior.

Step 4: Mobile routing

For real mobile users (not in-app browsers), the server returns a lightweight HTML page (~3KB, no external resources, inline CSS). The page contains:

• A <meta http-equiv="refresh"> tag with the URI scheme URL, fires immediately
• A small inline <script> that also attempts window.location = 'youtube://...' as a belt-and-suspenders
• A 1.5-second setTimeout that redirects to the web URL if the app didn't open
• A visible "Opening app..." spinner so users who do see the page briefly understand what's happening

Step 5: In-app browser fallback

If User-Agent matches a known in-app browser, the server skips the URI scheme entirely and serves a 302 to the destination web URL. Trying to deep-link from inside Instagram's in-app browser only confuses users and breaks the flow.

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. Bot detection, bot requests get a clean 410 Gone; they're excluded from analytics (see click fraud prevention)
2. Geo / device routing rules, if you've set up region-specific destinations, the matching destination is picked first
3. A/B testing splits, the traffic split is applied to the destination, picking variant A or B
4. Password gate, if a password is set, the user sees the prompt; on success, the redirect continues
5. Expiration check, if expires_at has passed, the user sees the "link expired" page; otherwise, continue
6. Deep link routing, the final destination URL 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. You see exactly which deep-link opens are from iOS vs Android, which platforms get the most native-app traffic, and which links have unusually high in-app browser ratios (a signal the link is getting shared inside social apps).

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.