Search⌘ K
AI Features
Home
Courses
Grokking the Mobile System Design Interview

Deep Linking and Universal Links in Mobile Applications

Explore the architecture and implementation of deep linking systems in mobile applications. Understand how Universal Links and deferred deep linking work across iOS and Android, managing URL routing through different app states. Learn about backend infrastructure for link management, attribution, and security best practices to prevent link hijacking and ensure reliable navigation.

We'll cover the following...

Deep linking is one of those features that appears simple from the user’s perspective but hides significant architectural complexity underneath. A user taps a link expecting to land on a specific screen inside the app, yet failures are common, redirects to the home screen, broken browser fallbacks, or links that simply do nothing. These issues are rarely caused by a single mistake. Instead, they emerge from misalignment across multiple layers: client-side routing, OS-level link handling, and backend configuration.

At its core, deep linking is a coordination problem. Mobile applications must correctly interpret incoming URLs, operating systems must trust and route those links to the right app, and backend services must provide the necessary verification and metadata. When any part of this chain is misconfigured, whether it’s domain association files, intent filters, or fallback handling, the entire experience breaks.

Designing reliable deep linking systems requires thinking beyond individual components and understanding how these layers interact to enable deterministic navigation. This naturally leads to the question: how do these pieces fit together in a production system?

Architecture of deep linking systems

Deep linking has evolved through three distinct generations, each solving limitations of the previous one.

  • Traditional URI schemes: This involves using custom protocols like myapp://product/123 to open an app directly. They are simple to implement but lack a verification mechanism, so any app can register the same scheme and intercept the link.

  • Universal Links (iOS) and App Links (Android): This includes using standard HTTPS URLs tied to a verified domain. The OS confirms ownership by verifying a server-hosted file before routing the link to the app.

  • Deferred deep linking: It extends this model to users who do not yet have the app installed, preserving the original link intent across an install flow.

How the OS resolves a link

When a user taps an HTTPS link, the operating system intercepts it before the browser handles it. On iOS, the OS fetches the AASAapple-app-site-association is a JSON file hosted at /.well-known/ on a domain that declares which URL paths should be opened by a specific iOS app instead of Safari. file from the link’s domain. On Android, it fetches the assetlinks.json file from the same well-known path. These files declare which app is authorized to handle URLs for that domain.

The OS caches these verification files, so the lookup does not happen on every tap. If the domain is verified and the app is installed, the OS launches the app and passes the full URL as a payload. The app’s URL router then parses the path and query parameters to determine which screen to display.

Fallback and deferred deep linking

When the app is not installed, the system must degrade gracefully. The link redirects the user to the App Store, Play Store, or a mobile web page that serves equivalent content. In a deferred deep linking setup, the backend attribution service stores the original link payload. After the user installs and opens the app for the first time, the client queries the attribution service, which returns the stored payload so the app can navigate to the originally intended screen.

Content-type headers and HTTP redirect codes (301 vs. 302) also matter. A 302 temporary redirect preserves the original URL for attribution tracking, while incorrect headers can cause the OS to misidentify the link type and fall through to the browser.

Attention: The most common production failure is a malformed or unreachable AASA/assetlinks.json file. If the OS cannot fetch and parse this file, all Universal Links and App Links for that domain silently fail.

The following diagram illustrates the end-to-end resolution flow from an external link tap through OS verification to in-app navigation or fallback.

Loading D2 diagram...
Deep link routing flow showing OS interception, domain verification, and app or fallback destination routing

Handling navigation across app states

Routing a URL to the correct screen is only half the problem. The app must also handle the link correctly depending on its current state, and there are three distinct states to account for.

  • Cold start means the app is not running. The OS launches the app and passes the URL as a launch parameter. The app must parse this URL during initialization, before rendering any default screen. The challenge is that dependency injection, authentication checks, and data loading may not yet be complete, so the deep link payload can be lost if it is consumed too early.

  • Background means the app is suspended in memory. The OS delivers the URL through a life cycle callback such as application(_:continue:restorationHandler:) on iOS or onNewIntent on Android. The app must decide whether to push the target screen onto the existing navigation stack, replace the current screen, or reset the stack entirely.

  • Foreground means the app is actively rendering. The same life cycle callbacks fire, but now there is a risk of race conditions if a navigation transition is already in progress when the deep link arrives.

A robust solution introduces a centralized DeepLinkRouter or NavigationCoordinator that queues incoming link intents, validates them, and dispatches navigation commands through a single code path regardless of app state. This prevents duplicated logic and ensures that authentication gates or incomplete initialization do not silently drop the link.

The following table summarizes how each app state affects deep link delivery and the recommended handling pattern:

App state

OS delivery mechanism

Key challenge

Recommended pattern

Cold start

Launch parameter / initial intent

Auth gates and dependency readiness may block navigation

Queue deep link intent, process after initialization completes

Background

Lifecycle callback (`continueUserActivity` / `onNewIntent`)

Reconciling with existing navigation back stack

Use NavigationCoordinator to decide push, replace, or reset

Foreground

Same lifecycle callback, app is active

Race conditions with in-progress transitions

Debounce or serialize navigation commands through a central router

Practical tip: During cold start, store the deep link URL in a pending queue and only process it after your dependency graph and auth state are fully resolved. This single pattern eliminates the most common class of “deep link lost on first launch” bugs.

Scalable link management and attribution

The client-side router handles navigation, but a production deep linking system also requires backend infrastructure to generate, resolve, and track links at scale.

Link generation and resolution

A link management service creates parameterized short links that encode metadata such as campaign ID, target screen, expiration time, and A/B test variant. These short links are stored in a link metadata database. When a user taps a short link, the request hits a CDN or edge layer that performs a 302 redirect to the appropriate destination. This edge resolution must be low-latency because every millisecond of redirect delay increases the chance the user abandons the flow.

Attribution pipeline

When a user clicks a deep link, the system records a click event containing the device fingerprintA combination of device attributes (IP address, OS version, screen resolution, language) used to probabilistically identify a device without a persistent identifier., referrer, timestamp, and campaign metadata. After the app opens, the client sends a matching signal to the attribution service, which correlates the click event with the app open using fingerprint matching or a clipboard token.

For deferred deep linking, the attribution service holds the original payload in a deferred deep link queue until the app is installed and opened for the first time. The client queries this queue on first launch, retrieves the stored intent, and navigates accordingly.

Scalability considerations include ensuring link resolution is CDN-backed for global low-latency access, the metadata store handles high write throughput during marketing campaigns, and attribution matching is idempotentAn operation that produces the same result regardless of how many times it is executed, preventing duplicate side effects like double-counted conversions. to avoid double-counting conversions. Industry patterns typically use dedicated short-link domains with edge-computed routing logic to minimize origin server load.

The following diagram shows the backend architecture supporting link management and attribution.

Loading D2 diagram...
Deep link backend lifecycle from creation through edge resolution, click tracking, and attribution matching

Security and validation of deep links

Deep links expand the app’s attack surface in several ways. Link hijacking occurs when a malicious app registers the same custom URI scheme and intercepts links meant for the legitimate app. Open redirect vulnerabilities allow an attacker to craft a link that passes through the app’s domain but redirects to a phishing page. Parameter injection manipulates query parameters to access unauthorized content or trigger unintended behavior.

Universal Links and App Links mitigate link hijacking because the OS verifies domain ownership before routing. Only the app whose developer controls the domain and hosts the correct verification file can claim those links. This is the primary security advantage over custom URI schemes.

On the server side, the backend must validate that incoming deep link parameters conform to expected schemas, that target resources exist, and that the requesting user has proper authorization. On the client side, the DeepLinkRouter should maintain a whitelist of allowed URL patterns, sanitize all parameters, and reject any link that does not match a known route.

For sensitive flows like password resets or payment confirmations, use time-limited signed URLs. The backend generates a token with an expiration timestamp and a cryptographic signature. The client passes this token back during navigation, and the server verifies it before granting access. This prevents replay attacks where an attacker reuses an old deep link.

Note: Domain verification files must be served over HTTPS with the correct application/json content type and no redirects. A single misconfiguration here silently disables all Universal Links for your domain.

Test Your Knowledge!

1.

What is the primary security advantage of Universal Links and App Links over custom URI schemes?

A.

They automatically encrypt all link parameters

B.

They verify domain ownership before routing links to the app

C.

They sanitize query parameters without developer intervention

D.

They prevent all forms of parameter injection attacks

1 / 2

Putting it all together with code

With the architecture and security model established, a practical implementation ties everything together through a centralized client-side router. The DeepLinkRouter receives a URL, matches it against a registry of known patterns, extracts and validates parameters, and dispatches navigation commands. This single entry point handles URLs from all three app states and enforces security validation before any navigation occurs. Unrecognized or malformed links are rejected at the gate.

The following Swift example demonstrates this pattern.

Swift
import Foundation
import UIKit
// Typed representation of all supported deep-link destinations
enum Route {
    case product(id: String)
    case profile(userId: String)
    case home
}
class DeepLinkRouter {
    // MARK: - Resolve
    /// Parses a URL into a Route, returning nil for unrecognized or invalid links.
    func resolve(url: URL) -> Route? {
        guard let components = URLComponents(url: url, resolvingAgainstBaseURL: false) else {
            return nil // Malformed URL
        }
        let path = components.path                          // e.g. "/product", "/profile", "/"
        let queryItems = components.queryItems ?? []
        // Helper: extract a named query parameter value
        func queryValue(for name: String) -> String? {
            queryItems.first(where: { $0.name == name })?.value
        }
        // Whitelist pattern matching — only explicitly listed paths are accepted
        switch path {
        case "/product":
            guard
                let id = queryValue(for: "id"),
                isValidProductID(id)                        // Sanitize: non-empty, alphanumeric only
            else { return nil }
            return .product(id: id)
        case "/profile":
            guard
                let userId = queryValue(for: "userId"),
                !userId.isEmpty                             // Basic non-empty validation
            else { return nil }
            return .profile(userId: userId)
        case "/", "/home":
            return .home
        default:
            return nil                                      // Reject any unrecognized path
        }
    }
    // MARK: - Navigate
    /// Dispatches UI navigation based on the resolved route.
    func navigate(to route: Route) {
        switch route {
        case .product(let id):
            // Push product detail screen with sanitized ID
            print("Navigating to product: \(id)")
        case .profile(let userId):
            // Push profile screen for the given user
            print("Navigating to profile: \(userId)")
        case .home:
            // Pop to root / show home tab
            print("Navigating to home")
        }
    }
    // MARK: - Private Helpers
    /// Validates that a product ID is non-empty and contains only alphanumeric characters.
    private func isValidProductID(_ id: String) -> Bool {
        guard !id.isEmpty else { return false }
        // Parameter sanitization: reject anything outside [A-Za-z0-9]
        let alphanumeric = CharacterSet.alphanumerics
        return id.unicodeScalars.allSatisfy { alphanumeric.contains($0) }
    }
}

This router becomes the single code path that the app calls from application(_:continue:restorationHandler:), from the launch parameter handler, and from any foreground callback. Every deep link flows through the same validation and dispatch logic.

Conclusion

The key architectural decisions in a deep linking system form a chain where each layer depends on the one before it. Choosing Universal Links and App Links over URI schemes provides domain-verified security and prevents link hijacking. A centralized DeepLinkRouter on the client handles all three app states through a single code path, eliminating duplicated navigation logic. On the backend, a link management service backed by CDN-level resolution delivers low-latency redirects, while an attribution pipeline supports deferred deep linking through device fingerprint correlation. Security is enforced at every layer through domain verification, URL pattern whitelisting, parameter sanitization, and signed URLs for sensitive flows.

Deep linking is a distributed system spanning edge infrastructure, backend services, and mobile clients. Its reliability depends on the correct configuration of domain verification files, the most common and costly failure point in production. Get the AASA and assetlinks.json files right, and the rest of the system has a solid foundation to build on.