Most QR codes send everyone to the same URL. That works fine for a simple webpage, but it becomes a problem the moment your destination depends on what device the scanner is holding. Send an Android user to an App Store link and they hit a dead end. Send an iOS user to a Google Play page and the experience falls apart before it begins. Device-based dynamic routing solves this cleanly — one printed QR code, three possible destinations, zero friction.
What Device-Type Routing Actually Does
When a user scans a dynamic QR code, the redirect server reads the User-Agent string from the scanner's HTTP request. That string identifies the operating system — iOS, Android, Windows, macOS, and so on. Based on a set of rules you configure in your QR dashboard, the server sends each device type to a different URL before the user even sees a loading screen.
This is distinct from time-based or language routing, which reads the clock or browser locale instead. Device routing reads hardware context. The two approaches can be stacked — more on that below.
The Core Use Case: App Install Campaigns
This is where device routing pays for itself within the first print run.
The problem without routing:
- You print a poster, flyer, or packaging insert with a single QR code
- iOS users need
apps.apple.com/... - Android users need
play.google.com/store/apps/... - Desktop visitors should probably land on your marketing page or a "download on your phone" prompt
- A single static URL can only satisfy one of these
With device routing, your configuration looks like this:
| Device detected | Destination URL |
|---|---|
| iOS | Apple App Store listing |
| Android | Google Play Store listing |
| Desktop / other | Web landing page with download prompts |
You print one QR code. It handles every device correctly. This is especially useful on product packaging, where you cannot reprint the box every time a platform changes its URL structure — because you're using a dynamic code, you update the destination in your dashboard without touching the printed asset. That's the practical edge of dynamic over static codes that makes the most difference in physical media.
Four Scenarios Where This Matters Beyond App Installs
1. Progressive Web App vs. Native App
If you have both a PWA and a native app, iOS and Android may have different capability levels. Route iOS to the native App Store install, Android to the PWA onboarding page (or vice versa), and desktop to a feature comparison.
2. PDF vs. Web Page
A restaurant menu QR on a table might route mobile users to a mobile-optimised HTML menu and desktop users (think: someone scanning with a tablet at the pass) to a printable PDF version. Small operational difference, big usability gain.
3. Loyalty Programme Enrollment
Some loyalty platforms have iOS and Android apps with separate deep-link formats. A single QR on a receipt or loyalty card can drop each user directly into the right app's sign-up flow rather than a generic web page.
4. Augmented Reality Experiences
AR features on iOS (ARKit) and Android (ARCore) often require different app entry points. A retail or events context where AR is part of the experience benefits immediately from routing users to the correct SDK-compatible page.
Stacking Device Routing With Other Conditions
Modern dynamic QR platforms — including Super QR Code Generator — let you apply multiple routing layers. A common stack:
- Layer 1 — Time: Is today within the campaign date range? If not, redirect to a "campaign ended" page.
- Layer 2 — Device: iOS → App Store, Android → Play Store, desktop → web.
- Layer 3 — Geo (optional): Route users in a specific country to a localised version of the store listing.
This layered logic runs server-side in milliseconds. From the user's perspective, the scan just works.
How to Set It Up: Practical Steps
- Create a dynamic QR code in your dashboard and point it to a placeholder URL.
- Open routing rules and add a condition: Device Type = iOS → [your App Store URL].
- Add a second rule: Device Type = Android → [your Play Store URL].
- Set a default (fallback) URL for all other devices — typically your main marketing page or a "get the app" landing page.
- Test by scanning with an iPhone, an Android device, and by opening the short URL in a desktop browser.
- Monitor per-device scan splits in your analytics dashboard. If Android scans are converting at a noticeably lower rate than iOS, that's a signal to investigate your Play Store page, not the QR code.
Tracking per-device performance is part of treating QR analytics as a decision-making tool rather than just a vanity metric.
Common Mistakes to Avoid
- Testing only on your own phone. Always test on both major OS types before printing.
- Forgetting the desktop fallback. People screenshot QR codes and open them on laptops — a broken fallback loses those users.
- Using static App Store short links instead of routing. Apple's and Google's own short links do not route cross-platform — an
apps.apple.comlink on Android just shows an error. - Not updating destinations after an app update. If your App Store or Play Store listing URL changes (rare, but it happens with app rebrands), update the routing rules, not the printed code.
Key Takeaways
- Device-type routing reads the scanner's OS and redirects to the appropriate URL before the page loads.
- The primary use case is app install campaigns that need to serve both iOS and Android from a single printed QR code.
- Always set a desktop fallback — it handles screenshotted codes and non-mobile scanners.
- Routing layers can be stacked (time + device + geo) for complex campaign logic.
- Test on real devices, not just emulators, before committing to print.
- Update destinations in the dashboard, never reprint, when app store links change.