Deep Linking, Conceptually

A regular app launch takes the user to wherever the app always starts — usually the home screen. A deep link is a URL that instead opens the app directly to a specific screen or piece of content, the same way clicking a link to one particular article on a news site takes you to that article, not the site's homepage.

myapp://product/42
https://myapp.com/product/42

Both of those are deep links to the same conceptual destination — a product detail screen for product 42 — expressed two different ways, which matters enough to be its own section below.

Why apps want this

A handful of very common situations all boil down to the same need: some event outside the app wants to point at a specific thing inside it.

• Push notification taps. "Your order shipped" should open the order's detail screen, not just launch the app and leave the user to go find it.
• Shared links. Someone shares a product with a friend — the friend tapping that link should land on that product, not the app's home screen with no idea what was shared.
• Marketing links. An email or ad campaign promoting a specific sale page should open directly to that sale, not force the user to navigate there themselves after opening the app cold.

In every case, the alternative — open to the home screen and make the user find their own way to the actual destination — is a real drop in the experience, and often a real drop in conversion for whatever action prompted the link in the first place.

1. Step 1

   User taps a link

   From a notification, a shared message, a browser, or an ad — myapp://product/42 or https://myapp.com/product/42.

2. Step 2

   OS opens the app

   The operating system recognizes the URL scheme or domain as registered to this app and launches it.

3. Step 3

   Linking config matches a path

   The navigation library's linking configuration maps the URL's path to a specific screen.

4. Step 4

   Navigator jumps to that screen

   The app lands directly on the matching screen (e.g. Product Detail, with id 42), not the home screen.

Registering the app with the OS

For an OS to know a given URL should open your app at all, the app has to register itself for that URL ahead of time, in one of two ways:

• A custom URL scheme, like myapp://. Simple to set up, but if the app isn't installed, the OS typically has nothing sensible to fall back to — the link just fails silently, or the browser shows an error about an unrecognized address.
• An associated universal link / app link domain, like https://myapp.com/product/42. This ties a real web domain you control to the app, verified through files hosted on that domain. The link looks like an ordinary web URL, works even if the app isn't installed (falling back to a real webpage instead of failing), and opens the app directly when it is.

Both mechanisms are widely used, often side by side — a custom scheme for internal or developer-facing links, and a universal/app-links domain for anything shared publicly, since it degrades gracefully instead of breaking outright.

Mapping a URL to a screen

Registering the app with the OS only gets you as far as "the app opens." Something still has to decide what to show once it does — that's the job of the navigation library's linking configuration: a mapping from URL paths to specific screens.

Conceptually, that mapping says things like "a product/:id path corresponds to the Product Detail screen, and whatever value is in the :id position becomes that screen's id param" — which ties directly back into the params concept from the previous lesson. A URL is really just another way of expressing "navigate to this screen with these params," arriving from outside the app instead of from a button press inside it.

The exact configuration syntax for expressing that mapping varies across navigation library versions, which is why this lesson describes the concept rather than one exact current shape of it — but the underlying idea (URL path in, matching screen and params out) is stable and worth carrying forward regardless of which specific syntax a given version uses.

What to remember

• A deep link is a URL that opens the app directly to a specific screen or state, not just the home screen.
• The main motivations are push notification taps, shared links, and marketing links — all cases where something outside the app wants to point at something specific inside it.
• The app has to be registered with the OS via a custom URL scheme or a universal/app-links domain, so the OS knows to open it for matching URLs.
• A universal/app-links domain degrades gracefully to a real webpage if the app isn't installed; a bare custom scheme typically does not.
• A linking configuration maps URL paths to specific screens (and their params) in the navigator — the bridge between "a URL arrived" and "the right screen is now showing."