Design Mobile Deep Linking and Universal Links

By /
⏱ 3 min read

Deep linking — the ability to open a specific screen in your app from a URL — is fundamental to mobile UX. A link in an email, a Google search result, a friend’s text message: each should open the right screen with the right context. The interview tests whether you understand the platform mechanics, the deferred-link case, and the routing architecture.

Custom URL schemes

myapp://product/123. Original mechanism. Problem: any app can register the scheme, leading to conflicts.

Universal Links (iOS)

HTTPS URLs your app can intercept. Apple verifies via a JSON file at /.well-known/apple-app-site-association. If the app is installed, link opens in app; if not, in Safari.

App Links (Android)

Same pattern: HTTPS URLs verified via /.well-known/assetlinks.json. Android opens the app if installed.

  • Same URL works on web and mobile
  • No “app not installed” failure — gracefully falls back to web
  • Verified ownership prevents conflicts
  • Better SEO (real URLs)

Routing inside the app

When a deep link opens the app:

  1. Parse the URL into a route + parameters
  2. Determine if the user is signed in
  3. Route to the destination screen with the parameters
  4. Optionally fetch additional data based on the link

Scenario: user clicks a marketing link, app is not installed, they install from the app store, and you want them to land on the original destination after install.

Implementation:

  1. Marketing URL captures campaign data (UTM, link target)
  2. Sends user to App Store / Play Store
  3. After install, on first launch, app fetches the deferred link data from a service (Branch, AppsFlyer, Adjust, or a homegrown server)
  4. App routes to the original destination

Tools: Branch, AppsFlyer, Adjust handle the cross-store attribution. Apple SKAdNetwork (iOS) and Android Install Referrer also support similar patterns.

If the deep link points to authenticated content:

  1. App checks auth state
  2. If signed in, route to destination
  3. If not, show login screen
  4. After login, route to original destination

Sharing from your app

The “share” button generates a universal link. Best practices:

  • The link works on web (so non-app users can see content)
  • The link gracefully promotes the app (smart banner on web)
  • Track link clicks for engagement analytics

Server-side validation

Both platforms verify ownership via files at well-known paths:

  • iOS: https://yourdomain.com/.well-known/apple-app-site-association
  • Android: https://yourdomain.com/.well-known/assetlinks.json

These must be served over HTTPS with proper Content-Type. Typos here cause silent failures.

Routing architecture

Modern app routing:

  • iOS: NSURLSession with universal link handling; SwiftUI deep-link API
  • Android: Navigation Component with deep-link support; intent filters in manifest
  • React Native: react-navigation with linking config
  • Flutter: go_router, Flutter’s built-in deep-link API

Common bugs

  • Universal links not working in Slack/Notes apps (some apps strip the universal-link behavior)
  • Routing fails silently when the user is in a sign-up flow
  • Links from email open in Safari instead of the app (iOS sometimes does this for “long-press” cases)
  • Deferred links failing because the attribution service never fired

Frequently Asked Questions

Should I use Branch / AppsFlyer or build my own attribution?

For most apps, use a vendor. Building your own deferred-link attribution well takes engineering effort that vendors have already done.

Do universal links work for QR codes?

Yes. The QR encodes a URL; the system detects universal links and opens the app if installed.

What about iMessage and other messaging apps?

Some messaging apps render universal links as native cards (preview metadata). Provide good Open Graph tags for these.

Scroll to Top