Home› Blog› Deep Link Implementation: The Complete Guide for Apps
App-Entwicklung

Deep Link Implementation: The Complete Guide for Apps

25. July 2026

Deep link implementation is one of the most impactful decisions you can make when building a mobile app. Done correctly, it eliminates friction, drives user re-engagement, and connects your app seamlessly to web content, email campaigns, and third-party platforms. Done poorly, it creates broken user experiences that cost you conversions and retention.

This guide walks your development team through every stage of deep link implementation – from choosing the right linking strategy to deploying, testing, and monitoring links in production. Whether you are building your first mobile app or modernizing an existing one, you will find concrete steps, real-world examples, and actionable recommendations throughout.

Most teams underestimate what deep link implementation truly encompasses. It is not simply adding a URL scheme to your app manifest. A complete implementation covers four interconnected layers:

1. Link type selection – Choosing between URI schemes, Universal Links (iOS), and Android App Links

2. Server-side configuration – Hosting the required verification files on your web domain

3. App-side handling – Writing the routing logic that maps incoming URLs to specific screens

4. Fallback management – Defining what happens when the app is not installed or the link cannot be resolved

Skipping any of these layers leads to partial implementations that fail under real-world conditions. According to Google's Android developer documentation, verified App Links require both proper intent filters in the manifest and a correctly hosted Digital Asset Links file – neither alone is sufficient.

Before writing a single line of code, your team must select the right link type for your platform and use case:

For most SMBs building cross-platform apps in 2024, the recommended baseline is Universal Links on iOS combined with Android App Links – with URI schemes retained only as a legacy fallback for older OS versions.

A successful deep link implementation starts with a planning phase that defines your link structure, ownership, and maintenance responsibilities before any code is written.

Your link architecture determines how URLs map to in-app destinations. A flat, unscalable structure like `myapp://open` forces you to pass all context as query parameters and becomes unmanageable at scale. A well-structured hierarchy looks like this:

Use your actual domain for App Links and Universal Links. This is non-negotiable for verified linking – both iOS and Android resolve these links against hosted configuration files on your domain.

Identify All Entry Points

Map every place a deep link might originate:

1. Push notifications

2. Email marketing campaigns

3. SMS messages

4. Social media posts and ads

5. QR codes in physical or digital materials

6. Web-to-app banners

7. Other apps linking to yours

Each entry point may have different requirements. Push notifications, for example, often need deferred deep links – links that preserve the destination even when the user must first install the app before opening it.

The server-side configuration is where many implementations break. Both Apple and Google require you to host specific files at well-known paths on your HTTPS domain.

Apple App Site Association (AASA) File

For Universal Links, create a file at `https://yourdomain.com/.well-known/apple-app-site-association` with no file extension. A minimal example:

json
{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "TEAMID.com.yourcompany.yourapp",
        "paths": ["/products/*", "/orders/*", "/promotions/*"]
      }
    ]
  }
}

Critical requirements: the file must be served over HTTPS with a `Content-Type` of `application/json`, without redirects. Apple's CDN fetches this file during app installation and caches it – changes can take 24–48 hours to propagate to existing users.

For Android App Links, host a file at `https://yourdomain.com/.well-known/assetlinks.json`:

json
[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.yourcompany.yourapp",
      "sha256_cert_fingerprints": ["AA:BB:CC:..."]
    }
  }
]

Use your release keystore fingerprint for production builds and a separate entry for your debug keystore during development. Missing or incorrect fingerprints are the single most common cause of App Links failures in production.

App-Side Implementation: Routing and Handling

Once the server configuration is in place, your app needs to receive incoming links and route users to the correct screen.

Android Implementation

In your `AndroidManifest.xml`, add an intent filter to the activity that handles deep links:

xml
<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="app.yourcompany.com" />
</intent-filter>

The `android:autoVerify="true"` attribute triggers the OS-level verification process against your `assetlinks.json` file. Without it, the link opens in a disambiguation dialog rather than going directly to your app.

In your `Activity` or `NavController`, parse the incoming intent:

kotlin
val uri = intent.data
if (uri != null) {
    when {
        uri.pathSegments.firstOrNull() == "products" -> {
            val productId = uri.lastPathSegment
            navigateToProduct(productId)
        }
        uri.pathSegments.firstOrNull() == "orders" -> {
            val orderId = uri.lastPathSegment
            navigateToOrder(orderId)
        }
        else -> navigateToHome()
    }
}

iOS Implementation

In your `AppDelegate` or `SceneDelegate`, implement the `application(_:continue:restorationHandler:)` method:

swift
func application(_ application: UIApplication,
                 continue userActivity: NSUserActivity,
                 restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> Bool {
    guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
          let url = userActivity.webpageURL else { return false }
    return handleDeepLink(url: url)
}

Your `handleDeepLink` function should parse the URL path and delegate to your navigation layer. Avoid placing navigation logic directly in the AppDelegate – use a dedicated `DeepLinkRouter` class to keep the codebase maintainable.

Standard deep links fail when the app is not yet installed. Deferred deep links solve this by persisting the intended destination through the install process. Here is how the flow works:

1. User clicks a deep link (app not installed)

2. User is redirected to the App Store or Play Store

3. User installs and opens the app for the first time

4. The app retrieves the original intended destination

5. User is routed directly to the correct screen

Implementing deferred deep links from scratch requires fingerprint-based attribution or platform-specific APIs. Most teams use a third-party service such as Firebase Dynamic Links (now deprecated as of August 2025), Branch, or Adjust to handle this reliably. If you are starting a new implementation, evaluate current alternatives before committing to any provider.

Across hundreds of mobile projects, the same errors appear repeatedly. Avoid these from the start:

Deep link implementation is not a one-time task. Links break when apps update, domains change, or server configurations are modified. Establish a monitoring routine:

Document your link schema in a shared specification that product, engineering, and marketing teams can all reference. When a campaign manager creates an email campaign, they should know exactly which URL patterns are valid and what each one does.

Use this checklist before shipping any deep link implementation to production:

1. ✅ AASA file hosted correctly on iOS domain (HTTPS, no redirect, correct Content-Type)

2. ✅ `assetlinks.json` hosted on Android domain with correct SHA-256 fingerprint

3. ✅ Intent filters and entitlements configured in both Android and iOS apps

4. ✅ All route patterns tested on physical devices running minimum supported OS version

5. ✅ Fallback behavior defined for unauthenticated users and missing content

6. ✅ Deferred deep link handling implemented for marketing and campaign links

7. ✅ Web fallback pages live for all deep link destinations

8. ✅ Analytics tracking attached to every link entry point

9. ✅ Link schema documented and shared with all relevant teams

10. ✅ Monitoring alerts configured for server-side file availability

For further reading, explore the full range of topics on mobile app development and strategy on our blog – including testing and analytics guides that complement this implementation walkthrough.

If your team is planning a new mobile app or refactoring an existing deep linking setup, the details matter enormously. A technically correct implementation reduces support tickets, improves campaign performance, and creates the seamless user experience your customers expect. The investment in getting it right the first time pays back immediately in reduced debugging time and higher conversion rates on every channel that uses links to drive users into your app.

Schedule a free initial consultation →

Have questions about this topic? Get in Touch.