Deep Link Routing: Mermaid Flowchart Diagram

About Source

Deep link routing describes the process by which a URL — received from a push notification, email, social media post, or web browser — opens a mobile app and navigates the user directly to the correct in-app screen rather than the app's home screen.

There are two primary mechanisms. URI scheme deep links (e.g., myapp://products/42) are custom URL schemes registered in the app's manifest. Any app can claim any custom scheme, so they carry no security guarantee — a malicious app could register the same scheme and intercept links. Universal links (iOS) and App Links (Android) address this by using standard HTTPS URLs (e.g., https://myapp.com/products/42). The OS verifies ownership by fetching a signed JSON file (apple-app-site-association or assetlinks.json) from the domain before granting the app authority to handle those URLs.

When the OS receives a deep link, it first checks whether the app is installed. If not, the fallback is typically the App Store or Play Store listing, or a web page at the same URL. If the app is installed, the OS passes the URL to the app via an AppDelegate or intent handler callback.

Inside the app, a router parses the URL path and query parameters and maps them to a specific screen or action. The router must also handle the cold start case, where the app isn't running — it needs to initialize essential state before attempting navigation. If the deep link requires authentication and no session exists, the user is redirected to the login screen, with the original destination preserved so navigation can resume after sign-in.

For notification-triggered deep links specifically, see Push Notification Flow. For full cold start context, see App Launch Lifecycle.

Frequently asked questions

Deep link routing is the process by which a URL — arriving from a notification, email, or browser — opens a mobile app and navigates directly to a specific in-app screen rather than the home screen, using either a custom URI scheme or a verified HTTPS URL.

The OS intercepts the incoming URL, checks whether an installed app claims the scheme or domain, and if so launches or foregrounds the app and passes the URL via a delegate callback. The app's internal router parses the path and parameters, resolves the target screen, initialises required state, and performs the navigation.

Use universal links (iOS) or App Links (Android) whenever security matters. They require cryptographic domain verification via a hosted JSON file, so no other app can intercept them. URI schemes carry no ownership guarantee and should only be used for inter-app communication within a controlled ecosystem.

Neglecting the cold-start path — where the app must finish initialising before navigating — is the most common issue, resulting in navigation to the wrong screen or a crash. Other mistakes include not preserving the destination during an authentication redirect and forgetting to handle malformed or unknown URL patterns gracefully.

URI scheme links (e.g. `myapp://path`) are claimed by declaring a custom scheme in the app manifest; any installed app can claim the same scheme, making them hijackable. Universal links / App Links use standard HTTPS URLs and require the app to be cryptographically verified as the owner of the domain, eliminating the hijacking risk and enabling web fallback when the app is not installed.

mermaid

flowchart TD
    A([User taps deep link URL]) --> B{Link type?}
    B -- URI scheme: myapp:// --> C{App registered for scheme?}
    B -- Universal Link / App Link --> D[OS fetches apple-app-site-association or assetlinks.json]
    D --> E{Domain verified?}
    E -- No --> F[Open in browser as regular URL]
    E -- Yes --> C
    C -- No --> G[Redirect to App Store / Play Store]
    C -- Yes --> H{App currently running?}
    H -- Yes: foreground --> I[Pass URL to app via openURL callback]
    H -- No: cold start --> J[Launch app process]
    J --> K[Initialize core app state]
    K --> I
    I --> L[Deep link router parses URL path and params]
    L --> M{Route recognized?}
    M -- No --> N[Navigate to home screen]
    M -- Yes --> O{User authenticated?}
    O -- No --> P[Save destination URL]
    P --> Q[Navigate to login screen]
    Q --> R[User completes authentication]
    R --> S[Restore saved destination URL]
    S --> T[Navigate to target screen]
    O -- Yes --> T
    T --> U([User arrives at destination screen])