Most teams configure deep linking once at launch and never look at it again. That is exactly when problems start. A domain migration, CDN change, expired configuration, or redirect rule can quietly stop a working deep link from opening the right screen, with no obvious error telling your team what went wrong.

For users, the result is simple: they tap a link expecting a specific product, campaign, or account screen and end up somewhere else, or in the browser. This guide explains how mobile app deep linking works, why Universal Links and App Links fail in production, how to debug them, and what you need to maintain them reliably after launch.

What Is Mobile App Deep Linking?

Mobile app deep linking is a link that opens a specific screen inside an app instead of the app’s home screen or a browser. A standard link to a product page drops a user on your app’s home screen if it opens the app at all. A deep link to that same product opens the app directly on that product’s screen, skipping navigation the user would otherwise have to do manually.

The Four Types of Deep Links

Custom URI Scheme

A custom URI scheme uses a proprietary link format like myapp://product/123 that only works if the app is already installed and only when tapped from a context that recognizes the scheme. Custom schemes are not reliable for links shared outside the app, an email client or messaging app often does not recognize a custom scheme and either fails silently or shows a broken link, since there is no fallback if the app is not installed.

Universal Links (iOS) and App Links (Android)

Universal Links on iOS and App Links on Android use standard HTTPS URLs that open the app if installed and fall back to a browser if not, verified through a domain ownership file hosted on your server. Because these use real HTTPS URLs rather than a custom scheme, they work reliably from any context, email, social media, SMS, without the fallback failures custom schemes produce.

Deferred Deep Linking

Deferred deep linking routes a new user to specific in-app content after they install the app, remembering the original link’s destination through the install process itself. Neither Universal Links nor App Links natively support this, since the app is not installed yet when the link is tapped, which means deferred deep linking for new-user acquisition flows requires a third-party provider, covered later in this guide.

How the OS Decides to Open Your App

Domain Verification With AASA and assetlinks.json

iOS checks for an apple-app-site-association (AASA) file hosted at your domain’s root, and Android checks for an assetlinks.json file in the same location, both proving your app is authorized to handle links for that domain. The OS fetches this file, confirms it lists your app’s identifier, and only then registers the domain to open your app instead of a browser. This verification happens once per app install or update, not on every link tap, which is part of why a broken configuration file can go unnoticed for a long time, existing installs keep working off a verification result cached from before the file broke.

What Happens When Verification Fails

Verification failure sends every link for that domain to a browser instead of the app, silently, with no error surfaced to the user or a way for them to know the app was supposed to open. This is the specific failure mode that makes stale configuration files dangerous, the link still technically works, it just no longer does what it was built to do, and nothing in the user experience signals that anything is wrong.

Why Deep Links Fail in Production

The leading cause of deep link failures in production is a stale or missing Associated Domains configuration file, not application code. [NEEDS VERIFIED SOURCE for the specific failure-rate figure and study] Domain migrations, CDN provider switches, hosting changes, and framework-level redirects are the most common events that silently break an AASA or assetlinks.json file after launch, since none of these changes touch application code directly, they touch server configuration a mobile team rarely owns or monitors.

Building a Deep Link Maintenance Process

What Breaks Deep Links After Launch

Four events commonly break a working configuration after launch: a domain migration that does not carry the verification file to the new domain, a CDN change that alters how static files are served, a hosting provider switch that resets server configuration, and a framework-level redirect rule that accidentally intercepts the verification file’s URL path. None of these are mobile app changes, which is why a mobile team frequently has no visibility into them until links start failing.

Who Should Own the Verification Files

A named owner, not “the team,” should hold responsibility for these files, since diffuse ownership is exactly how a stale file goes unnoticed for months. The most workable model assigns ownership to whoever owns the domain’s DNS and hosting configuration, marketing ops, DevOps, or a platform team, with a standing requirement that any domain, CDN, or hosting change triggers a verification file check before the change ships, not after.

A Recommended Audit Cadence

Audit both configuration files monthly at minimum, and immediately after any domain, CDN, or hosting change regardless of the regular schedule. A monthly check confirms the file is still reachable over HTTPS, returns the correct Content-Type header, and still lists the correct app identifiers, a five-minute check that catches most silent breakage before it accumulates into a meaningful share of failed links.

How to Debug a Broken Deep Link

Step 1, Confirm the Config File Is Reachable

Fetch the AASA or assetlinks.json file directly over HTTPS and confirm it returns a 200 status with valid JSON, not a redirect, a 404, or an HTML error page. A redirect is the most common silent failure here, since the OS does not follow redirects when fetching this file, a domain migration that 301s the old URL to a new one breaks verification even though the file itself loads fine in a browser.

Step 2, Check the Content-Type Header

Confirm the file is served with a Content-Type of application/json, since some servers default to text/html or text/plain for files without a recognized extension, which causes the OS to reject an otherwise valid file. This is a common failure specifically after a CDN or hosting migration, since the new server’s default configuration frequently does not match the old one’s content type handling.

Step 3, Check OS-Level Verification Status

Check the platform-specific verification status directly, Apple provides a validator through Xcode and associated developer tools, and Android’s adb shell pm get-app-links command shows current verification status for a given package. This step confirms whether the OS has actually re-verified the domain since the file last changed, since a fixed file does not immediately re-verify on every device.

Step 4, Account for Propagation Delay

Confirm enough time has passed for propagation before assuming a fix has failed, since iOS commonly caches the AASA file for 24 to 48 hours after a change, meaning a fix does not reach all users immediately. Testing immediately after a fix, on a device that already cached the old verification result, frequently shows the link still failing even though the underlying file is now correct.

Do You Need a Third-Party Deep Linking Provider?

Native Universal Links and App Links are enough for an app that only needs to route existing installs to specific screens. A third-party provider, Branch, AppsFlyer, or Adjust among common options, becomes necessary once you need deferred deep linking for new-user acquisition, routing someone who taps an ad or referral link to specific content immediately after they install the app for the first time, since neither Apple nor Google’s native link systems support this natively. Providers also add attribution reporting, which app referral programs typically want anyway, on top of the linking capability. The tradeoff is an ongoing cost and a dependency on a third party for core navigation infrastructure, worth the investment specifically for acquisition-driven deferred linking, not necessary for basic in-app navigation between existing users and specific screens.

How App Tracking Transparency Affects Deep Linking

App Tracking Transparency restricts cross-app tracking and attribution, not deep linking itself, a common point of confusion. A deep link still opens the correct screen inside your app regardless of a user’s ATT choice. What ATT affects is a third-party provider’s ability to attribute that link tap to a specific ad campaign or referral source using cross-app identifiers, which is an attribution and measurement concern layered on top of deep linking, not a deep linking function itself. Reliable measurement of what’s actually working requires proper event tracking independent of ATT-restricted identifiers, covered in our guide to what to track in mobile app analytics.

Cost and Timeline to Implement Deep Linking

[NEEDS VERIFIED SOURCE for a current, specific cost and timeline range]. Native Universal Links and App Links implementation, without deferred deep linking, is a comparatively contained scope, configuring and hosting the AASA and assetlinks.json files, handling the resulting links in app code, and testing across both platforms. Adding deferred deep linking through a third-party provider adds SDK integration time on top of the native setup, plus the provider’s ongoing fee once live. The maintenance process covered above is not a one-time cost either, budgeting a recurring, if small, ownership responsibility matters as much as the initial implementation timeline.

Keeping Your Deep Links Working Long-Term

Deep linking that works at launch and breaks six months later after a domain migration nobody flagged is a maintenance failure, not a technical one. If you’re implementing deep linking for the first time or need a real audit of why links are failing in production, our mobile app development team can help you build both the initial setup and the ownership process that keeps it working. Get in touch to talk through your specific situation.

Frequently Asked Questions