K1.11.1deep link to specific screendesign

A deep link must open the specific screen, not the app's front door

Aliases: deep link · Universal Links · App Links · URL scheme

What it is

A deep link is an address of a particular screen inside an app, not a command to bring the app to the foreground. An order in mail, a thread in a push, a product on a web page should land on that order, that thread, that product—not the storefront, with a search left to the person. Opening the app onto the default screen is a technical success and a task failure. This entry is whether the landing is that screen. It is not what to do if the app is missing, not how to get back, and not whether parameters must be checked.

Why it happens

The OS hands a URL or app link to the app that claimed the route. If launch only runs the default root, the route is dropped and the person sees a cold start, not the object the link named. Three implementations fail often: the app registered "open me" but not a path; the path is registered but a login wall dumps people on home and forgets the target; the object is gone and home opens anyway instead of "this item is not here." A search box on home is not a repair: the link already carried an identifier, and searching throws that identifier away. If the app is already showing some other screen in recents, some systems only foreground it and skip the new route, which reads as "the link did nothing."

Where it stops holding

When a non-skippable compliance or safety step (identity check, a child mode) must run first, it may run first, but the original target must continue afterward rather than dying on home. First-run onboarding may also insert itself, and must store the original route the same way. A link whose entity is gone (ended campaign, delisted product) should land on an explanation page; that is still a specific result, not home. In-page anchors in a desktop browser are not this routing model; a website home redirect is not an in-app landing.

Applying it

  • Give every externally referenced object a stable route, and honor it after launch rather than opening the default screen and ignoring the path.
  • If login or onboarding must insert itself, write the original route as pending work and run it after. Do not hard-wire post-login to home.
  • Verify by tapping a link to a second-level object from mail or a note. The app should open that object. If home appears first, count the extra searches or taps to reach it: that count is the distance the deep link dropped.

Related

  • Within the group: K1.11.2 A missing target app needs a fallback path, not a dead end · K1.11.3 After an inter-app jump, the way back to the source must still exist · K1.11.4 Unchecked deep-link parameters become an attack surface
  • Adjacent: K8.01 Task continuity
  • Search terms: deep link · Universal Links · App Links

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/K1.11.1