Deep Linking in Mobile Apps

By Kokil Thapa | Last reviewed: September 2026

Deep linking in mobile apps connects a URL tap to a specific screen inside your installed app instead of a browser tab. That matters when email, SMS, push, QR codes, or social posts must open a product, booking, or document view directly. On production systems I maintain, the mobile team owns native routing while my Laravel or WordPress backend supplies consistent URLs and authenticated hand-offs through the WooCommerce REST API for mobile apps. This guide covers what actually breaks in production and how to design links that survive app store review, OS updates, and marketing campaigns.

What Is Deep Linking in Mobile Apps and Why Does It Matter?

A deep link is any link that opens content beyond your app's home screen. A shallow link opens the launcher icon. A deep link opens /orders/4821 or /lawyer/john-smith inside the installed binary.

Without deep linking in mobile apps, every campaign URL lands in Safari or Chrome. Users log in again. Carts reset. Push notification taps feel broken. Conversion drops because the friction is real and measurable.

Three business outcomes drive the engineering work:

• Acquisition: ad and social URLs open the app when installed, or the store when not.
• Retention: push and email taps land on the exact order, message, or booking.
• Attribution: campaign parameters survive the hop from web to app install.

On a legal-tech portal I built, document-upload reminders must open the client's case folder—not the login screen three taps away. The same pattern applies to client portals with document sharing and eCommerce order tracking.

How Do Custom URI Schemes Compare to Universal Links and App Links?

Mobile platforms offer three main mechanisms. Pick based on security needs, fallback behaviour, and whether you control the web domain.

Custom schemes are easy to register but any app can claim myapp://. A malicious app could intercept taps on some Android builds. HTTPS-based links with domain verification fix that.

Apple documents Universal Links in its Supporting Universal Links guide. Google documents App Links in the Android App Links training module. Read both before you ship.

When custom schemes still make sense

Use a custom scheme only as a secondary path. Some SDKs and older integrations expect it. Pair it with HTTPS links in email templates so users without the app still reach a web page.

How Do You Configure Universal Links and App Links on the Server?

Deep linking in mobile apps fails more often at the server layer than inside Swift or Kotlin. The association files must be reachable, valid JSON, and served without redirects.

On sister sites I deploy with Deployer 7 and GitLab CI, I treat these files like production config. A broken AASA file silently disables Universal Links with no user-visible error.

Apple App Site Association (AASA)

Host this file at https://yourdomain.com/.well-known/apple-app-site-association with no file extension. Content-Type should be application/json.

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "TEAMID.com.yourcompany.shopapp",
        "paths": ["/p/*", "/orders/*", "/account/*"]
      }
    ]
  }
}

Replace TEAMID with your Apple Developer Team ID. Paths support wildcards. Exclude admin routes explicitly if needed.

Android Digital Asset Links

Host assetlinks.json at https://yourdomain.com/.well-known/assetlinks.json.

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.yourcompany.shopapp",
      "sha256_cert_fingerprints": [
        "AB:CD:EF:..."
      ]
    }
  }
]

Use the signing certificate fingerprint from your release keystore. Debug and release builds need separate entries during development.

Apache configuration for association files

On Ubuntu servers where I run Apache and PHP-FPM, I serve AASA without redirects:

<Files "apple-app-site-association">
    Header set Content-Type "application/json"
</Files>

<Files "assetlinks.json">
    Header set Content-Type "application/json"
</Files>

A 301 from HTTP to HTTPS on the association path breaks iOS verification during CDN changes. Test with curl before every deploy.

How Should Your Laravel or WordPress Backend Design Deep Link URLs?

Native developers parse paths. Backend developers own the URL contract. If marketing changes slugs without telling the app team, deep links break silently.

On a production Laravel application, I keep web routes and deep-link paths identical. The same /bookings/{uuid} URL works in Blade, the API, and the mobile router.

1. Define a URL schema document shared by web, API, and mobile teams.
2. Use stable identifiers—UUIDs or numeric IDs—not slugs that change with SEO edits.
3. Return 404 for deleted resources so the app can show a friendly screen.
4. Pass auth tokens via secure exchange, never long-lived secrets in query strings.
5. Log link opens server-side for attribution and debugging.

Laravel route example

Route::get('/orders/{order:uuid}', function (Order $order) {
    if (request()->header('Accept') === 'application/json') {
        return new OrderResource($order);
    }

    return view('orders.show', compact('order'));
})->name('orders.show');

The mobile app registers /orders/* in its link handler. The web view and JSON API share one canonical path. That alignment mirrors good internal linking strategy for SEO—one URL, one meaning.

For WooCommerce-backed mobile clients, product and order endpoints must match the paths you advertise in campaigns. See the API development service page for how I structure these contracts on client projects.

Authenticated deep links

Never put a JWT in a marketing URL. Anyone who forwards the SMS can hijack the session.

A safer pattern:

• Generate a one-time token stored in Redis with a five-minute TTL.
• Embed ?t=abc123 in the deep link.
• App exchanges the token for a Sanctum or Passport session via POST.
• Invalidate the token immediately after use.

I use Redis caching patterns on Laravel apps for exactly this kind of short-lived state. The same Redis 8.10 instance can hold rate limits and token exchanges.

Validate JSON payloads during development with the JSON formatter tool before you paste association files into production.

What Are Deferred Deep Links and How Do Push Notifications Use Them?

A deferred deep link preserves the intended destination across app install. User taps an ad, installs from the store, opens the app, and lands on the product—not the home screen.

Implementation options in 2026:

• Platform APIs: Apple App Clips and Android Play Install Referrer carry context with privacy constraints.
• Third-party SDKs: Branch, AppsFlyer, and Adjust handle fingerprinting and pasteboard hand-off.
• Self-hosted: Store intent in a signed cookie on the web fallback, read it on first app launch via authenticated API.

Push notifications depend on deep linking in mobile apps to feel native. A booking reminder must open /bookings/abc, not the app root.

On the Adventure Third Pole Trek booking platform, supplier alerts and client confirmations share URL patterns with the web CRM. That consistency reduced support tickets after we aligned paths. Similar work appears in the Adventure Third Pole Trek portfolio case.

Read the push notifications for mobile apps article for payload structure. Put the deep link path in the data block, not only the notification title.

Testing checklist before launch

1. Tap link with app installed—cold start and background resume.
2. Tap link with app uninstalled—confirm store or web fallback.
3. Tap link on iOS and Android from Gmail, Messages, and Slack.
4. Verify association files with Apple's and Google's online validators.
5. Confirm logged-out users reach a login screen with return URL preserved.
6. Run mobile CI/CD with Fastlane smoke tests on staging builds.

Security review belongs in the same sprint. Open redirects in deep link handlers are a common finding during mobile app security basics audits.

How Do PWAs and eCommerce Backends Fit Into Mobile Deep Linking?

Not every business needs a native app. A progressive web app handles many deep-link use cases through standard HTTPS routes and service workers.

When clients do need native apps—payment flows with eSewa or Khalti, offline trekking itineraries, or florist checkout—the web and app must share one link vocabulary.

On WooCommerce and custom Laravel eCommerce builds like Quick And Easy Nepalese Grocery, I expose stable product and order URLs. The mobile wrapper consumes the same paths. Payment return URLs for eSewa integration in PHP apps and Khalti in Laravel must match what the app registers as handled links.

For Shopify clients, use the 2026-07 Admin API version or later when syncing product handles to app routes. Handle changes break links unless you map by numeric product ID internally.

Enterprise teams building booking or directory apps should treat deep link design as part of architecture review, not a marketing afterthought. The enterprise application development engagement model includes URL contracts in the planning phase.

Common production failures I have seen

These issues appear repeatedly across client projects:

• CDN caches a 404 for the AASA file after a bad deploy.
• Marketing adds UTM parameters that the app router does not strip before matching.
• Slug changes in WordPress break old email links with no redirect rule.
• Staging domains leak into production push payloads.
• Android release signed with wrong keystore—assetlinks mismatch.

Fix redirects at the web layer first. A website migration without link mapping destroys years of saved deep links in user inboxes.

Offline-first apps add another layer. Cached screens may show stale data if the deep link arrives without network. Coordinate with offline-first mobile app patterns so the router queues API fetches after navigation.

For Nepal-facing apps with Nepali content in URLs, normalise Unicode paths server-side. Tools like the Nepali Unicode converter help QA teams verify that encoded paths match what iOS passes to the handler.

Key Takeaways

• Prefer verified HTTPS Universal Links and App Links over bare custom URI schemes for production deep linking in mobile apps.
• Host AASA and assetlinks.json without redirects, with correct JSON content types, on every campaign domain.
• Keep web routes, API endpoints, and mobile path handlers on one shared URL schema document.
• Exchange one-time tokens for authenticated screens—never embed long-lived credentials in marketing links.
• Test cold start, background resume, and uninstall fallback on real devices before every major release.
• Align payment return URLs and push payload paths with backend routes so eCommerce deep links do not dead-end.

People Also Ask

What is the difference between a deep link and a universal link?

A deep link is any URL that opens specific in-app content. A Universal Link is Apple's verified HTTPS implementation of deep linking. Android's equivalent is an App Link. Both require server-side domain association files.

Do deep links work if the app is not installed?

Standard deep links open the browser or show an error if the app is missing. Deferred deep links store the intended path during install so the first launch can route correctly. Always ship a web fallback page with a store badge.

Can email clients break mobile deep links?

Yes. Some clients wrap URLs through security proxies. Use clean HTTPS links without javascript redirects. Test taps from Gmail, Outlook, and Apple Mail on both platforms before campaigns go live.

Who should own deep link URL design—the app team or backend team?

Both. Backend owns canonical paths, redirects, and association files. Mobile owns native routing and parameter parsing. Marketing and SEO should review slugs before they ship in paid campaigns.

Ship Deep Links That Survive Production

Deep linking in mobile apps is a cross-team contract—not a native-only feature. The server files, URL schema, auth exchange, and fallback pages matter as much as the Swift or Kotlin handler. Get those right and every push, SMS, and ad URL lands where the user expects.

If you are planning a Laravel or WooCommerce backend for a mobile client, map deep link paths during architecture—not after the app store deadline. Contact us to review your URL schema, association files, and API hand-off flow, or explore the e-commerce development and custom software development services for full-stack delivery.