OS-Based QR Routing: Send iPhone and Android Scans Correctly
OS-based QR routing means one printed QR code that sends each scanner to a different destination depending on the operating system of their phone: iPhone users go to the App Store, Android users to Google Play, and everyone else to a web page. It works because the code does not hold the final address. It holds a short redirect link, and a server decides where to send each scan at the moment it happens. That is also why the feature needs a dynamic QR code, not a static one.
TL;DR
- OS-based routing uses a dynamic QR code whose redirect server reads the scanning device and sends iOS, Android and desktop scans to separate destinations.
- Always set a default destination for desktops, unknown devices and anything the server cannot identify.
- If your app is installed, Universal Links (iOS) and App Links (Android) can open it directly. If not, the visitor lands on a web page or store listing.
- Test on real devices, with and without the app installed, before anything goes to print.
- Keep scan analytics privacy-light: routing by device type needs no personal data.
Table of Contents
- How OS-based QR routing works
- Where OS-based routing earns its place
- What destinations and fallbacks to support
- How to set up OS-based routing, step by step
- How to test iOS and Android routing
- What can stop OS routing from working
- Privacy: routing by device does not need personal data
- Reading the results
- Our perspective
- Try device routing with your own code
- FAQ
- Sources
How OS-based QR routing works
A static QR code encodes its destination directly. Whatever URL was typed in at creation is what every phone opens, forever, and it cannot be changed after printing.
A dynamic code encodes a short link on a redirect service instead. When someone scans it, the phone’s camera opens that short link, and the request reaches a server before the visitor sees any page. That server can look at the request and choose where to send it. We explain the mechanics step by step in our guide to QR redirected links.
For OS-based routing, the server reads the User-Agent, a text header every browser sends with its request. It usually contains the words iPhone, iPad or Android, plus browser and version details. The server applies your rules:
- Header mentions iPhone or iPad: redirect to the iOS destination.
- Header mentions Android: redirect to the Android destination.
- Anything else: redirect to the default destination.
The whole thing takes a fraction of a second, and the scanner sees only the final page. Because the rule lives on the server, you can change any of the three destinations later without touching the printed code.
Why the User-Agent is useful but not perfect
The User-Agent is the standard signal, but it is not a guarantee. An IETF draft on device user-agent strings warns that these values may not correctly represent hardware and software, and that they can be spoofed or altered between the client and the server. The IETF’s own RFC on client hints adds that user-agent detection has limits: it cannot reliably identify every variable, it relies on a device database that must be kept current, and it does not play well with caching.
For QR routing this has a practical meaning. Most scans from ordinary phones are identified correctly. A few will not be: privacy-focused browsers, in-app scanners that present an unusual header, and desktop browsers set to mimic a phone. That is why a default destination is not optional. It is the safety net for every scan the rules cannot place.
Where OS-based routing earns its place
The feature is most useful when the right answer genuinely differs by platform.
App downloads. The classic case. One code on a poster, a shop window or a box sends iPhone users to the App Store listing and Android users to the Google Play listing. Without it, you either print two codes and ask people to pick, or print a web page that adds a tap. We cover the printed-material side in never reprint app download QR codes again.
Platform-specific instructions. A setup guide for a smart device, a wallet pass, or a loyalty card may need different steps on iOS and Android. Routing sends each person to the right version.
Different file or pass formats. Some digital tickets and passes are delivered in a format that suits one platform better than the other. The default page can offer both options for desktop visitors.
Campaign testing. Once routing is in place, scan analytics show the split between iOS and Android. That tells you which platform your audience actually uses, which can shape the next campaign.
A worked example
Imagine a restaurant group with a table-card QR code for its ordering app. The routing rules might be:
| Scanner | Destination | Why |
|---|---|---|
| iPhone or iPad | App Store listing for the ordering app | One tap to install |
| Android phone | Google Play listing | Same, on the right store |
| Desktop or unknown | Web ordering page | Works with no install |
The same card works for every guest. If the group later launches a seasonal menu in the app, the destinations can be updated in the dashboard and the printed cards stay in use.
What destinations and fallbacks to support
Good routing is mostly good fallback design. Think in layers.
Layer 1: the app, if it is installed
Both major platforms have a way for a normal web link to open an app directly. Apple explains that QR codes containing a website URL can open an installed app through Universal Links, and if the app is not installed, the URL simply loads in Safari, where the page can point to the App Store. Apple’s documentation describes the setup: you place an apple-app-site-association file on your HTTPS server listing the URLs your app handles, and you add an associated-domains entitlement to the app, as set out in its Universal Links guide.
Android has the equivalent in App Links. Android’s developer documentation notes that on Android 15 and higher, server-side dynamic rules in assetlinks.json allow fine-grained path-level routing, while manifest intent filters still define the broad scope of the domain association.
The key point for QR users: these mechanisms depend on the link being on a domain your app is associated with. If your QR short link uses a domain you do not control, the app will not open directly, and the visitor goes to the web page instead. A branded or custom domain makes the app-opening route possible. For the printed-material and tracking-parameter side, see our piece on deep linking with QR codes.
Layer 2: the store listing
If the app is not installed, the iOS and Android destinations should be the store listings. Check the links on a real device. A link that opens the store website in a desktop-style view is a common annoyance.
Layer 3: a web page
The default destination should be a real page, not a dead end. Good defaults include:
- A landing page with both store badges and a short explanation.
- The mobile web version of the service, if one exists.
- A simple page that asks the visitor to scan again from a phone.
Branded landing pages also lift the experience for scanners the rules cannot identify. We have collected examples of branded code landing pages that show how this can look.
How to set up OS-based routing, step by step
The steps are the same whichever tool you use, as long as it supports dynamic codes with device rules.
- Create a dynamic code. Static codes cannot route. In QRlytics you can start from the dynamic QR code generator.
- Collect your three URLs. The App Store listing, the Google Play listing and the default web page. Open each on a phone to confirm they load.
- Add device rules. Assign the iOS URL to iPhone and iPad, the Android URL to Android, and the web page as the default.
- Add tracking parameters if you need them. If your analytics read UTM tags, add them to each destination so the iOS and Android visits are labelled correctly.
- Style the code. Use your brand colours and keep strong contrast between code and background. Leave the quiet zone (the blank margin) around the code intact.
- Test before printing. See the next section.
- Print and monitor. Watch scan counts by device and location, and adjust destinations if the data shows a problem.
How to test iOS and Android routing
Testing is where most routing problems are caught, and it takes about fifteen minutes.
- Scan with an iPhone and an Android phone. Use the built-in camera on each, not just a third-party scanner.
- Test with the app installed and not installed. Delete the app from a spare device to see the first-time experience.
- Test on a desktop. Open the short link in a desktop browser to confirm the default page appears.
- Try a second browser. On iPhone, open the link in a different browser app. On Android, try a non-default browser. Results should still be sensible.
- Check the analytics. After your tests, confirm the scans appear with the right device type. That also confirms tracking works before real traffic arrives.
- Print a proof. Scan the printed sample at the real size and distance it will be used.
If something misroutes, check the rules first, then the destination URLs, then the domain association files if you rely on app opening.
What can stop OS routing from working
Most failures come from a short list of causes.
| Problem | What happens | Fix |
|---|---|---|
| No default set | Unidentified devices get an error or the wrong page | Always set a default web page |
| Unusual User-Agent | A scan is placed in the wrong group | Make the default page useful for everyone |
| Store link broken or region-locked | Visitor sees an error | Test links on real devices and check regional availability |
| Domain not associated with the app | App does not open directly | Use a domain you control and publish the association files |
| Low-contrast or tiny code | Code will not scan at all | Test the printed proof |
| Desktop scan of an app-only destination | Visitor sees a store page they cannot use | Send desktop to a web page |
Notice that the first line of defence is the same each time: a clear default. The routing itself is simple. The care goes into what happens when it cannot decide.
Privacy: routing by device does not need personal data
Choosing a destination by operating system only requires the device type from the request. It does not need a name, an email address or a cross-site profile. That makes it a good fit for privacy-first measurement.
Regulators have been consistent on the broader principle. The US Federal Trade Commission’s privacy report noted that large platform providers, including operating systems and browsers, that comprehensively track online activity raise privacy concerns, and it said mobile privacy disclosures should be short, effective and readable on small screens. Those points are from 2012, but they still describe good practice for a QR landing page: tell people plainly what you measure, in a few lines they can read on a phone.
Some practical habits:
- Collect only what the campaign needs. Device type, rough location and scan time are enough for most QR reporting.
- Prefer analytics that do not depend on cookies. Our guide to cookieless QR analytics explains how.
- Keep your disclosure short and visible on any landing page that collects more. See our QR data privacy guide for a checklist.
- Link the landing page’s privacy information from the page itself, not from the print.
If you want to see how others connect QR-driven visits to measurable outcomes and clear privacy notices, this case study on tracking QR-driven visits is relevant reading for marketers.
Reading the results
Routing is only half the value. The other half is knowing what happened after the scan.
With device-level analytics you can answer questions such as:
- What share of scans came from iOS and what share from Android?
- Which cities and countries produce the most scans?
- Which print placement (poster, packaging, flyer) performs best?
- Do scans fall back to the default page often, which would suggest an identification problem?
A large default share on a campaign aimed at phones is a flag. It may mean many visitors are scanning from unusual apps or that rules need adjusting. Our guide to QR code tracking and the walkthrough on tracking from scan to conversion show which metrics to watch and how to organise them.
Our perspective
We see the same pattern again and again: a team prints thousands of codes, the campaign runs, and months later someone changes the app, the store listing or the landing page. If the code was tied to a fixed address, the print run is wasted.
OS-based routing is a good example of why we built QRlytics around dynamic codes. The rule that sends iPhone users one way and Android users another sits on the server, so you can adjust it whenever your app or campaign changes. The printed code never has to.
We also stand behind a simple promise: codes created during an active subscription keep working, even after cancellation or a billing problem. For a routed code on packaging or signage, that matters more than any single feature. A routing rule is only valuable if the code is still alive in two years.
Our advice is to keep routing rules few and clear: iOS, Android, and a strong default. Test on real phones, read the scan data, and refine from there.
The
Try device routing with your own code
QRlytics lets you create dynamic codes, update destinations after printing and see scan analytics, including device and location. You can start on the free plan without a credit card, and paid plans on the pricing page add unlimited codes, advanced analytics and API access. If you want to see how scans are reported before you commit, start with QR codes with analytics.
To build your first routed code, open the dynamic QR code generator, add your iOS, Android and default links, and test it on two phones before you print.
FAQ
Can a static QR code route by operating system?
No. A static code contains the destination itself, so every phone opens the same address. Routing needs a dynamic code that points to a redirect server, where rules can send each scan to a different place.
Does the QR code know whether my phone is an iPhone or an Android?
The code itself does not. The server that handles the redirect reads the User-Agent header sent by the scanning phone’s browser and applies your rules. Because that header is not always accurate, a default destination should always be set.
Will the app open directly if it is installed?
It can, if your link is on a domain associated with your app through Universal Links on iOS or App Links on Android. If the app is not installed, the visitor lands on a web page, where you can offer the store link. Without that domain association, the visitor goes to the web page or store listing.
Does routing by device break privacy rules?
Choosing a destination by operating system needs only the device type, not personal data. Keep the data you collect to what the campaign needs, and show a short, clear privacy notice on any landing page that collects more.
Can I change the routing after the code is printed?
Yes, with a dynamic code. You can edit the iOS, Android or default destination in the dashboard at any time, and the printed code stays the same.
Sources
- QR Code Recognition on iOS 11, Apple Tech Talks
- Support Universal Links, Apple developer documentation
- Device stock User-Agent draft, IETF
- RFC 8942, HTTP Client Hints, IETF
- Protecting Consumer Privacy in an Era of Rapid Change, FTC report