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:

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.

Originally published by Appy Marketing on DEV Community.

Here is a practical acceptance checklist for a small team preparing packaging, a poster, or a counter card.

1. Write down the expected destination

Before testing, define the result for each supported audience. A simple matrix prevents “the link opened” from becoming the entire acceptance test.

Operating system detection is not proof of store availability. Confirm that the intended listing is available to the audience in the countries where the campaign will run.

2. Test the final print, at the intended distance

A successful scan from a design preview does not validate the printed result. Use a proof at the actual production size, with the intended material and finish.

Try the distance and angle someone would use in the real setting. Check reflections, folds, curved packaging, low contrast, and surrounding graphics. Preserve clear space around the code. If a logo is added, test the finished version again.

Keep a copy of the exact approved asset so later artwork changes do not silently invalidate the test.

For a companion reference on sizing and placement, see our Appy QR-code sizing and testing guide.

3. Follow the redirect after the scan

Check the exact store listing, not just whether a store opens. A typo can send traffic to a different app or a page that is unavailable in a particular region.

Also test the desktop fallback. Someone may photograph a poster, receive the URL in a message, or open it on a laptop. The fallback should explain what the app does and offer a useful next step.

If your destination can be edited after printing, document who owns it. Test the printed QR again after changing any destination.

4. Separate store routing from opening an installed app

These are different requirements:

• Store routing chooses a store or web destination.

• Opening a specific screen in an installed app depends on the app's link handling and platform configuration.

• Restoring a destination after a new installation requires a separate deferred linking flow.

Passing the first test does not establish that the other two work. If the campaign promises an in-app destination, include both installed and not-installed cases in the acceptance matrix.

5. Define what the measurement means

A redirect request is not an installation. Preview services, repeated visits, and automated traffic can affect counts, depending on how the measurement system filters them.

Keep the stages separate: link requests, store arrivals where observable, installations, and the in-app action that matters to the campaign. Mark unavailable stages as unknown rather than inferring them from clicks.

6. Assign a release owner

Record the asset version, destination URLs, test devices, results, and person responsible for future changes. Recheck destinations before reusing old print assets.

The acceptance question is concrete: can someone scan this actual asset, reach the correct destination, and complete the next step under realistic conditions?

Prepared by an AI agent using Appy's existing QR campaign guidance. No device tests or campaign results are claimed. Cover illustration generated with AI.

Originally published by Appy Marketing on DEV Community.