A mobile app link can work perfectly on phones and still leave someone reading an email on a laptop with no useful next step.
Treat the default web destination as part of the app journey. It should explain what the app is, offer explicit store choices, and make switching to a phone straightforward.
Separate the routing URL from the fallback page
Use two distinct addresses:
- Routing URL: the stable link you distribute in emails, bios, and QR codes.
- Fallback page: the web page served when a routing rule does not select a store.
For example, a routing URL might send a phone to a store and a laptop to a page at example.com/get-app. That page can display a QR code containing the routing URL.
Avoid setting the fallback destination to the routing URL itself. That creates a cycle: route → fallback → route. Also avoid encoding only the desktop page in the QR if your intention is to send the scanning phone through device routing.
As an implementation reference, Appy's one-link setup guide explains the default destination and platform overrides. This article is published by Appy Marketing; the guide is our own educational resource.
A desktop browser does not identify the reader's phone
A laptop request cannot tell you whether its reader owns an iPhone, an Android phone, both, or neither. A wide viewport is also a layout signal, not a store preference.
MDN documents why user-agent detection is unreliable. Treat automatic routing as a convenience and keep explicit choices available on the fallback page. Do not hide one store because a desktop browser looks like a particular operating system.
Give the page three jobs
Confirm the app. Show its name and a short explanation consistent with the message that brought the visitor there. Someone following a link about expense scanning should not need to search a generic homepage for the relevant app.
Offer a choice. Provide clearly labeled links such as “View Example App on the App Store” and “View Example App on Google Play.” Use your actual public listing URLs. Avoid a generic “Continue” link whose destination becomes clear only after clicking.
This follows the principle in W3C's guidance on link purpose: readers should be able to determine what a link does from its text or context. If you use image badges, give the links accessible names too.
Support the device switch. Add a QR code with a short instruction: “Scan with your phone to choose the appropriate store.” Display a copyable routing URL alongside it. The text alternative matters when a camera is unavailable or someone is already reading on the phone they would use to scan.
If a usable web version exists, offer it as a separate, clearly named action. Do not imply that a store visit or a QR scan installs the app automatically.
Write acceptance criteria before styling
Use a small checklist to define the behavior you intend to verify:
| Situation | Expected result |
|---|---|
| Desktop visitor opens the distributed link | App identity, both store choices, and phone handoff are visible |
| Visitor chooses a named store | The correct app listing opens |
| Phone scans the desktop page's QR | The encoded routing URL is used, with no fallback loop |
| Visitor cannot scan | A readable, copyable link remains available |
| Routing cannot classify the device | The fallback still offers useful choices |
These are proposed checks, not results from a device test. Run them with your actual destinations before relying on the page.
Finally, record the events separately: fallback viewed, store link selected, and routing link opened. A store click is an outbound action; it is not proof of an installation. Keep that distinction in dashboards and campaign reports.
A useful fallback lets the reader finish the next step even when automatic routing has too little information.
AI disclosure: This article was written by an AI agent using the linked sources. It does not report firsthand device tests or campaign results. The cover is an AI-generated editorial illustration, not a product screenshot.
Top comments (0)