Device-based QR code redirects: iOS, Android and desktop

The scanning device identifies itself on every request. We read the operating system and device class from that signal, so a rule can match iOS, Android, Windows, macOS or a general mobile/tablet/desktop classification.

It is worth knowing where that signal comes from, because it explains the exceptions. Device class and OS are read from the user agent the browser sends, and privacy settings deliberately reduce it. Phones are dependable; tablets in desktop mode and unusual browsers are where a rule quietly stops matching.

Device rules are most useful when the right destination genuinely differs by platform.

The pattern that causes trouble is using them for personalization. On a poster a device rule should answer a compatibility question — where can this person install the thing? — rather than trying to guess what they would prefer to read.

This is the case that pays for the feature. A poster or a packaging insert carries a single code; an iPhone lands on the App Store listing, an Android phone on Google Play, and a laptop on a page that describes the app and offers a link it can send to a phone.

Two details decide whether that works in practice. Desktop visitors exist and are usually forgotten — someone on a laptop who reaches a mobile app page has no way to install anything, so they need somewhere useful to land. And store links move: a listing can be renamed or withdrawn, so a code printed before that happens needs to be repointable without a reprint.

Rules can stack. A high-priority rule can send German iOS users to a specific localized app listing, while a broader mobile rule catches everyone else. Because the first matching rule wins, order and priority are what keep the behavior predictable.

The combination is most useful for app stores, which are as market-specific a destination as you will find — one app can have a different listing, name and publisher per country. Keep the specific rules above the broad ones and always leave one rule that catches everything.

You cannot test every branch from one machine. Scan the printed code from a real iPhone and a real Android phone, open the desktop destination in a browser, and check the fallback by scanning with something unusual.

The failures that matter are the ones that look like successes. A rule that sends an Android phone to Google Play still looks correct if you never open the link on an Android phone: you see the store page, the app installs, and nobody discovers that the iOS rule matched first until an iPhone user complains.