A missing target app needs a fallback path, not a dead end

What it is

When the app a deep link points at is not installed, the tap must not die on the system "cannot open" dialog or a blank. A fallback is the next path prepared in advance: a web version of the same task, a store install that still carries the original target, or a read-only copy of the content. After install, the first launch should still try to open that object rather than restarting from home. This entry is where to go when the app is missing. It is not which screen to open when it is present, not how to return from the target, and not parameter checking.

Why it happens

A custom URL scheme usually fails outright when the app is absent; the OS has no default page to open. Universal Links / App Links hand the same URL to the web first and to the app when installed, so an uninstalled tap can at least open a browser—if that URL actually has a web page, not a private scheme only the app can parse. A store fallback solves "usable later," not "this tap now": the person wanted a route, a ticket, a meeting already starting. By the time they return from the store, the object may have expired. A deferred deep link (install, then feed the original URL in on first launch) joins install to landing, but only if the identifier survives the install. Fallback is not "any homepage": a marketing page still breaks the task at "not installed."

Where it stops holding

On a managed device that forbids both installs and an external browser, fallback may be only an in-app note that a named app is required and cannot be installed. Capabilities with no web equivalent (Bluetooth device debugging, payment that must use a secure element) must not fake a web version; say which capability is missing. When the store is unavailable in a region, jumping to it is a second failure; use a reachable web page or say the app is not offered there. Malicious links also ride fallbacks into stores. The fallback page itself has to come from a trusted host; an arbitrary target URL is not a safe store parameter.

Applying it

• Prefer public HTTP addresses that also have a web page. Uninstalled taps open that page; installed taps go to the app.
• If the task can only be done in the app, explain why when it is missing, offer a store install, and carry the object identifier into first launch rather than stopping on a welcome screen.
• Verify by tapping the same link on a device with the target app removed. A usable web page or an install path that still names the object should appear, not a system error. After install, first launch should still attempt the original object. A welcome screen means the fallback distributed the app and dropped the task.

Related

• Within the group: K1.11.1 A deep link must open the specific screen, not the app's front door · 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: deferred deep link · Universal Links · fallback