The Complete Deep Linking Guide for Mobile Developers

TL;DR: Deep linking routes users directly to specific content inside a mobile app instead of the app's home screen. There are four types: standard deep links (custom URL schemes), Universal Links (iOS), App Links (Android), and deferred deep links. Each solves a different piece of the mobile linking puzzle. This guide covers how they all work, when to use each, and how to implement them.

What Is Deep Linking?

Deep linking is a technique that sends users directly to a specific screen or piece of content inside a mobile app, rather than opening the app's home screen or a web browser. When someone taps a deep link, they land exactly where you intended: a product page, a user profile, an article, a checkout flow, or any other in-app destination. Deep links use URLs to encode both the target app and the content path within it, allowing external sources like emails, social media posts, ads, and websites to hand off context to the app at launch time.

For developers building mobile apps, deep linking is the bridge between the open web and the closed world of native apps. Without it, every link sends users to a browser, the app store, or the app's home screen. With it, you can build connected experiences that feel instant and intentional.

Why Deep Linking Matters

Mobile apps live in sandboxes. Unlike the web, where any URL can link to any page on any site, native apps are isolated by design. There is no universal address bar for app content. Deep linking solves this by giving every screen in your app a URL that the operating system can resolve.

Without deep linking, the typical user journey looks like this:

1. User sees a link to a product in an email
2. User taps the link
3. Browser opens to a mobile web page
4. Web page shows a banner saying "Open in app"
5. User taps the banner
6. App opens to the home screen
7. User manually navigates to find the product

That is seven steps for something that should take one. Each step is a drop-off point. Industry data consistently shows that conversion rates decrease with every additional tap or redirect in a mobile flow.

With deep linking:

1. User taps the link
2. App opens directly to the product page

Two steps. No friction. No wasted time. The user gets what they wanted, and you keep the engagement.

The Developer Case for Deep Linking

Beyond user experience, deep linking unlocks several technical capabilities that are difficult or impossible to achieve otherwise:

• Content sharing. Users can share specific screens from your app, not just the app itself. The recipient lands on the exact content.
• Marketing attribution. You can track which links, campaigns, and channels drive app opens and installs.
• Onboarding personalization. New users who arrive through a specific link can see tailored first-run experiences based on the link's context.
• Re-engagement. Push notifications and emails can route users back to specific content, not just relaunch the app.
• Cross-platform continuity. A link works whether the user has the app installed, needs to install it, or is on a device where the app is not available.

Types of Deep Links

Not all deep links work the same way. The technology has evolved significantly over the past decade, and there are now four distinct types, each with different capabilities and trade-offs.

Standard Deep Links (Custom URL Schemes)

Standard deep links use custom URL schemes to identify the target app. Instead of https://, they use a scheme registered by the app, like myapp:// or example://.

For example:

myapp://product/123
myapp://profile/jane
myapp://settings

When the operating system sees a URL with the myapp:// scheme, it checks whether any installed app has registered that scheme. If one has, it launches the app and passes the URL. The app then parses the path to determine which screen to show.

On iOS, you register a custom URL scheme in your app's Info.plist:

<key>CFBundleURLTypes</key>
<array>
  <dict>
    <key>CFBundleURLSchemes</key>
    <array>
      <string>myapp</string>
    </array>
  </dict>
</array>

On Android, you declare an intent filter in your AndroidManifest.xml:

<intent-filter>
  <action android:name="android.intent.action.VIEW" />
  <category android:name="android.intent.category.DEFAULT" />
  <category android:name="android.intent.category.BROWSABLE" />
  <data android:scheme="myapp" />
</intent-filter>

Limitations of custom URL schemes:

• No fallback. If the app is not installed, the URL goes nowhere. The user sees an error or nothing happens. There is no graceful degradation to a web page or app store listing.
• No uniqueness guarantee. Any app can register any scheme. Two apps registering the same scheme creates undefined behavior. On iOS, the system picks one arbitrarily.
• No verification. There is no proof that the app claiming myapp:// actually owns the domain myapp.com. This is a security gap.
• Blocked in many contexts. Many email clients, social media apps, and in-app browsers strip or block custom URL schemes entirely.

Custom URL schemes were the first generation of deep linking and are now considered legacy. They are still useful for app-to-app communication on the same device, but they are not reliable for links shared across the web, email, or social media.

Universal Links (iOS)

Universal Links are Apple's modern deep linking mechanism, introduced in iOS 9. They use standard HTTPS URLs instead of custom schemes. When a user taps a Universal Link, iOS opens the associated app directly. If the app is not installed, the same URL loads in Safari as a normal web page.

This solves the biggest problem with custom URL schemes: Universal Links always work. The user either gets the app experience or the web experience. No dead ends.

How Universal Links work:

1. You host an Apple App Site Association (AASA) file at https://yourdomain.com/.well-known/apple-app-site-association
2. The AASA file declares which URL paths your app handles
3. When a user installs your app, iOS downloads the AASA file from your domain
4. iOS stores the association locally on the device
5. When the user taps a matching HTTPS URL, iOS checks the local association and opens your app
6. Your app receives the full URL and routes the user to the correct content

The AASA file looks like this:

{
  "applinks": {
    "details": [
      {
        "appIDs": ["ABCDE12345.com.example.myapp"],
        "components": [
          { "/": "/product/*", "comment": "Product pages" },
          { "/": "/invite/*", "comment": "Invitation links" },
          { "/": "/share/*", "comment": "Shared content" }
        ]
      }
    ]
  }
}

The appIDs value combines your Apple Team ID (ABCDE12345) and your app's bundle identifier (com.example.myapp). The components array defines which URL paths your app handles.

Requirements for Universal Links:

• Your domain must serve the AASA file over HTTPS with a valid certificate
• The AASA file must be served with Content-Type: application/json
• The AASA file must be accessible without redirects (Apple's CDN fetches it directly)
• Your app must include an Associated Domains entitlement (applinks:yourdomain.com)
• The app must be signed with a provisioning profile that includes the Associated Domains capability

Common Universal Links pitfalls:

• AASA caching. Apple's CDN caches your AASA file aggressively. After updating it, changes can take hours or days to propagate. During development, you can use Apple's AASA validator to check the cached version.
• Same-domain taps do not trigger Universal Links. If the user is already browsing yourdomain.com in Safari and taps a link to another page on yourdomain.com, iOS treats it as normal web navigation. Universal Links only trigger from cross-domain contexts. This is why many deep linking services use a separate short-link domain.
• Long press reveals the choice. If a user long-presses a Universal Link, iOS shows options to open in Safari or the app. If they choose Safari, iOS remembers that preference for the entire domain. The user must long-press again and choose "Open in App" to re-enable the behavior.
• In-app browsers bypass Universal Links. Links opened inside apps like Twitter, Facebook, or Instagram often load in an in-app SFSafariViewController or WKWebView. These embedded browsers handle Universal Links inconsistently. Some respect them, others do not.

App Links (Android)

App Links are Android's equivalent of Universal Links, introduced in Android 6.0 (Marshmallow). They use verified HTTPS URLs to open your app directly, with web fallback for users who do not have it installed.

How App Links work:

1. You host a Digital Asset Links file at https://yourdomain.com/.well-known/assetlinks.json
2. The file declares which apps are authorized to handle URLs from your domain
3. You declare intent filters in your app's manifest with autoVerify="true"
4. At install time, Android verifies the association by fetching the assetlinks file
5. Once verified, matching URLs open your app automatically

The assetlinks.json file looks like this:

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.myapp",
      "sha256_cert_fingerprints": [
        "AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78:90"
      ]
    }
  }
]

The sha256_cert_fingerprints array contains the SHA-256 hash of your app's signing certificate. This cryptographically verifies that only your app can claim URLs from your domain.

Your Android manifest needs intent filters:

<intent-filter android:autoVerify="true">
  <action android:name="android.intent.action.VIEW" />
  <category android:name="android.intent.category.DEFAULT" />
  <category android:name="android.intent.category.BROWSABLE" />
  <data android:scheme="https" android:host="yourdomain.com" />
  <data android:pathPattern="/product/.*" />
</intent-filter>

The android:autoVerify="true" attribute tells Android to verify the domain association at install time. Without it, Android treats the link as a regular intent and shows a disambiguation dialog ("Open with...") instead of opening your app directly.

Key differences from Universal Links:

• Android uses SHA-256 certificate fingerprints for verification. iOS uses Team ID and bundle ID.
• Android verifies at install time and periodically re-verifies. iOS caches the AASA via Apple's CDN.
• Android intent filters support regex-like path patterns. iOS AASA components support wildcards and exclusions.
• If verification fails on Android, the link still works but shows a disambiguation dialog. On iOS, the link falls through to Safari silently.

Deferred Deep Links

Deferred deep links solve the hardest problem in mobile linking: what happens when a user taps a link but does not have the app installed yet?

With standard deep links or even Universal Links and App Links, the best you can do for a new user is redirect them to the app store. After they install and open the app, the original link context is gone. The user lands on the home screen with no idea how to find the content they originally wanted.

Deferred deep links preserve the link context across the app install. The word "deferred" refers to the fact that the deep link is delivered to the app after a delay, not at the moment the user tapped it.

How deferred deep links work:

1. User taps a link (e.g., https://links.example.com/product/123)
2. The link service records the click context: destination path, UTM parameters, timestamp, and a device fingerprint based on IP address, user agent, and other signals
3. The user does not have the app, so they are redirected to the app store
4. The user installs the app and opens it for the first time
5. The app's SDK sends device signals to the link service
6. The link service matches the install to the original click using a cascade of matching strategies
7. The SDK returns the matched deep link data to the app
8. The app navigates the user to the intended content

The matching step is the core technical challenge. Since there is no persistent identifier that survives the journey from browser to app store to app (cookies do not cross that boundary, and Apple restricts device tracking), the system must use indirect signals.

Common matching strategies, in order of reliability:

Strategy	Mechanism	Accuracy
Referrer	Google Play install referrer (Android only)	Deterministic
Device ID	IDFV on iOS, deterministic re-engagement matching	Deterministic
Fingerprint	IP + User Agent + screen size + other signals	Probabilistic (~90-95%)

The best implementations use a cascade approach: try deterministic matching first, fall back to probabilistic matching only when needed. This maximizes accuracy while maintaining coverage across platforms.

Deferred deep link use cases:

• Referral programs. Alice shares a referral link. Bob taps it, installs the app, and Alice gets credit. The deferred deep link carries Alice's referral code through the install.
• Content sharing. A user shares a recipe link on social media. A follower taps it, installs the cooking app, and lands directly on that recipe.
• Marketing campaigns. An ad links to a specific in-app promotion. New users who install through the ad see the promotion on first launch.

Comparison of Deep Link Types

Feature	Custom URL Schemes	Universal Links (iOS)	App Links (Android)	Deferred Deep Links
URL format	myapp://path	https://domain/path	https://domain/path	https://domain/path
Works if app not installed	No	Falls back to web	Falls back to web	Redirects to store, delivers context after install
Domain verification	None	AASA file	assetlinks.json	Depends on link service
Security	Low (no verification)	High (Apple-verified)	High (certificate pinning)	Varies by implementation
Works in all contexts	No (blocked by many apps)	Mostly (some in-app browser issues)	Mostly	Yes (uses HTTPS URLs)
Preserves context through install	No	No	No	Yes
Implementation complexity	Low	Medium	Medium	High

How Deep Linking Works: The Full Flow

Understanding the complete flow helps when debugging issues or building a custom implementation. Here is what happens step by step when a user taps a deep link.

Step 1: User Taps a Link

The link is a standard HTTPS URL, like https://links.example.com/abc123. This URL could appear in an email, a text message, a social media post, a QR code, or a web page.

Step 2: Link Service Resolves the URL

The link service receives the HTTP request. It looks up the slug (abc123) to find the link configuration: the target app, the in-app destination path, fallback URLs, and metadata. It also inspects the User-Agent header to determine the user's platform (iOS, Android, or desktop) and whether the request comes from a bot (for social media preview cards).

Step 3: Platform Routing

Based on the platform:

• iOS user: The service returns a redirect to the Universal Link URL, or directly to the app store if no Universal Link is configured
• Android user: The service returns a redirect to the App Link URL, or to the Play Store
• Desktop user: The service redirects to a web fallback URL
• Bot/crawler: The service returns an HTML page with Open Graph and Twitter Card meta tags so the link renders a rich preview on social media

Step 4: OS Resolves the App Association

If the user's platform supports it and the app is installed:

• iOS checks its local AASA cache. If the URL matches a registered path, iOS opens the app and passes the URL.
• Android checks its verified App Links. If the URL matches a verified intent filter, Android opens the app and passes the URL as an intent.

If the app is not installed, the URL loads in the browser (which may show a web page or redirect to the app store).

Step 5: App Handles the Deep Link

The app receives the URL and parses it to determine which screen to show. On iOS, this happens in application(_:continue:restorationHandler:) for Universal Links or scene(_:continue:) for SceneDelegate apps. On Android, it happens in the activity's onCreate or onNewIntent by reading the intent data.

Step 6: Content Routing

The app's router maps the URL path to an internal screen. For example, /product/123 maps to the product detail screen with ID 123. The app fetches the necessary data and renders the screen.

Deep Linking Challenges

If deep linking sounds straightforward in theory, the implementation reality is considerably more complex. Here are the most common challenges developers face.

iOS Quirks

Universal Links are fragile in practice. The AASA file must be served perfectly. Any issue with SSL certificates, redirects, content types, or caching breaks the entire flow silently. There is no error message. The link just opens in Safari instead of the app.

Paste-and-go bypasses Universal Links. If a user copies a URL and pastes it into Safari's address bar, iOS treats it as direct navigation, not a link tap. Universal Links do not trigger. This catches many developers off guard during testing.

In-app browsers are inconsistent. Each social media app handles links differently. Some apps open links in SFSafariViewController (which supports Universal Links), others use WKWebView (which does not), and the behavior can change between app versions without notice.

The user can break it. If a user long-presses a Universal Link and chooses "Open in Safari," iOS remembers that preference for the entire domain. The user must manually reverse this choice. There is no API to detect or reset it.

Android Fragmentation

Verification failures are common. App Link verification depends on Android fetching your assetlinks.json at install time. If the fetch fails (network issues, server downtime, DNS problems), the app falls back to showing a disambiguation dialog instead of opening directly. Some Android OEMs (particularly in China) block the verification request entirely.

OEM customizations break standard behavior. Device manufacturers like Samsung, Xiaomi, and Huawei modify Android's default link handling. Samsung Internet has its own app linking behavior. Xiaomi's MIUI sometimes overrides verified App Links with its own browser.

Chrome's intent system adds complexity. When an App Link is tapped in Chrome, Android handles the routing. But if the link is tapped in a WebView inside another app, the behavior depends on how that app configured its WebView.

Cross-Platform Consistency

Building deep links that work identically on iOS and Android requires handling two completely different systems (AASA vs. assetlinks, Universal Links vs. App Links, different URL handling APIs) and presenting a single consistent experience to users and marketers who just want "one link that works everywhere."

Attribution Accuracy

Matching an app install to the link that caused it is an inherently lossy process. There is no cross-boundary identifier between the mobile browser and the app store. Since Apple removed access to IDFA (Identifier for Advertisers) without explicit user consent in iOS 14.5, and both platforms continue tightening privacy restrictions, probabilistic fingerprinting is becoming less accurate over time. The industry is moving toward server-side referrer passing and privacy-preserving attribution models.

Deep Linking Use Cases

Content Sharing

The most common use case. A user shares a link to a specific item, article, recipe, listing, or profile. The recipient taps the link and lands directly on that content in the app. If they do not have the app, they see the web version or get directed to the app store.

Good content sharing links also include Open Graph metadata so the link renders with a title, description, and image when shared on social media or messaging apps.

Referral Programs

Referral links encode the referrer's identity so that both parties receive credit when the new user installs and signs up. Deferred deep links are essential here because the referral code must survive the app install flow. Without deferred deep linking, you lose attribution for every new user who did not already have the app.

Marketing Campaigns

Email campaigns, paid ads, social media posts, and influencer partnerships all benefit from deep links that route users to specific in-app content. UTM parameters attached to the link provide campaign attribution data. Deep links with analytics tell you not just that someone clicked, but whether they opened the app, which content they saw, and whether they converted.

Re-engagement

Users who installed your app weeks ago but have not opened it recently can be re-engaged through email or push notifications containing deep links. Instead of a generic "Come back!" message that opens the home screen, you can link to new content, a personalized recommendation, or a time-limited offer. The specificity of the deep link dramatically improves tap-through and re-engagement rates.

Onboarding Flows

When a new user arrives through a specific context (an invitation to a team workspace, a shared document, a promotional offer), deferred deep links let you customize the onboarding experience. Instead of a generic sign-up flow, the user sees an onboarding screen that acknowledges why they are here and gets them to the relevant content faster.

Debugging Deep Links When They Don't Open

Most deep linking failures show up as one of a handful of symptoms, and each one has a different root cause. When a link does not open the way you expect, the first job is to name the symptom precisely, because "deep links are broken" almost always resolves to a specific, fixable problem. Here are the four most common failures and where to go for each.

• A Universal Link opens Safari instead of your app. iOS could not verify that your app is allowed to handle the URL, so it fell through to the browser. This is an association problem: the AASA file, the entitlement, or how you are testing. Start with Universal Links Not Opening? Every Cause and How to Fix Each One, which triages the whole chain and rules out the testing mistakes that account for more than half of these reports.

• The AASA file itself is the suspect. If you have narrowed it to the apple-app-site-association file, redirects, content type, the appIDs Team ID prefix, or a stale cached copy, work the dedicated checklist in Apple App Site Association Not Working: The iOS Universal Links Debug Checklist. It is a command-by-command walkthrough, ordered by probability.

• Android App Links open a chooser dialog instead of your app. When autoVerify fails, Android stops opening your app directly and shows a disambiguation dialog. The cause is usually the assetlinks.json file, a missing or wrong SHA-256 fingerprint, or a verification fetch that never succeeded. See Android App Links autoVerify Failed: The assetlinks.json Debug Checklist.

• A deferred deep link never fires after install. The user tapped a link, installed the app, and landed on the home screen with no context. This is an attribution and matching problem, not a routing one. See Deferred Deep Linking on iOS: How to Implement It in Swift.

If you are not sure which symptom you have, the Universal Links triage guide is the right entry point. It sorts "opens Safari" from "opens the app but does nothing" in the first step.

Deep Linking and Install Attribution

A deep link is not just a router. It is also an attribution signal. Every tap carries context about where the user came from, and the same infrastructure that opens the right screen can record which link, campaign, or channel drove that open and the install behind it. Linking, attribution, and analytics are three views of the same event, and treating them as one system is what turns a working deep link into a measurable one.

The hard part is connecting an install back to the click that caused it. There is no identifier that survives the trip from a mobile browser, through the app store, into a freshly installed app. So a link service matches the install to the original click using a cascade of signals, from most reliable to least:

• Referrer. On Android, the Play install referrer passes the original link parameters through the store. Deterministic.
• Device ID (IDFV). On iOS, the vendor identifier gives an exact match for re-engagement, when a user who already installed the app clicks again. Deterministic, and exempt from the tracking prompt because it is scoped to your apps only.
• Fingerprint. When neither deterministic signal is available, the service compares device characteristics (IP, user agent, language, screen, timezone) recorded at click time against the same signals at install time. Probabilistic, with confidence that decays the longer the install lags the click.
• Raw signals. A fallback where the app sends its raw device characteristics and the server computes the match itself, since the device cannot know its own public IP.

The first successful match wins, which keeps accuracy high without sacrificing coverage across platforms. For the full cascade, confidence scores, and the privacy model behind it, see the install attribution concepts page. The deferred deep link case, where attribution and routing happen together at first launch, is covered in Deferred Deep Linking on iOS.

Frequently Asked Questions

What is deep linking in mobile apps?

Deep linking is a technique that sends users directly to a specific screen or piece of content inside a mobile app, instead of opening the home screen or a browser. Deep links use URLs to encode both the target app and the content path, so emails, ads, and websites can hand off context to the app at launch.

What is deferred deep linking?

Deferred deep linking preserves a link's context across an app install. When someone taps a link without the app, they go to the app store, and after they install and open it, the SDK matches the device to the original click and routes them to the intended content. It is essential for referrals and campaigns.

Universal Links vs App Links: what is the difference?

Universal Links are Apple's iOS mechanism, verified through an AASA file at your domain using Team ID and bundle ID. App Links are Android's equivalent, verified through assetlinks.json using SHA-256 certificate fingerprints. Both use HTTPS URLs and fall back to the web if the app is not installed. If Android verification fails, the link shows a chooser dialog; iOS falls through to Safari silently.

How does deep linking work on iOS and Android?

A link service resolves the URL, inspects the User-Agent to detect the platform, and redirects accordingly. On iOS, the system checks its local AASA cache and opens the app for a matching path. On Android, it checks verified App Links and passes the URL as an intent. If the app is not installed, the URL loads in the browser.

How does WarpLink handle deep linking and install attribution?

WarpLink provides Universal Links, App Links, deferred deep links, and install attribution through one dashboard and API, with open source MIT SDKs for iOS, Android, and React Native that resolve links in a single method call. It matches installs to clicks using a cascade of referrer, device ID, fingerprint, and raw signals.

Getting Started with Deep Linking

Implementing deep linking from scratch requires hosting and maintaining AASA and assetlinks.json files, building a link resolution service, handling platform detection, implementing deferred deep link matching, and keeping everything working as iOS and Android change their requirements.

WarpLink handles all of this. You get Universal Links, App Links, deferred deep links, and install attribution through a single dashboard and API. The open source SDKs for iOS, Android, and React Native handle link resolution in a single method call.

If you are migrating from Firebase Dynamic Links, the guide to replacing Firebase Dynamic Links walks through the process step by step. Still weighing your options? See Firebase Dynamic Links alternatives compared for the full field.

To see how WarpLink fits into the bigger picture, read Introducing WarpLink or jump straight to the quickstart guide to create your first deep link in under five minutes.