One QR code, two app stores: send iPhone users to the App Store and Android users to Google Play

One QR code, two app stores: send iPhone users to the App Store and Android users to Google Play

Every agency running an app-install campaign hits the same small, annoying problem. The client has an app on both the App Store and Google Play, the print run is one poster, one flyer, one till-point sticker, and the QR code on it can only point at one URL. The usual fix is to print two codes side by side, label them "iPhone" and "Android", and hope the customer picks correctly. It works, but it looks amateurish, it wastes half the print real estate, and it puts the burden of self-selection on someone who just wants to download an app.

A single QR code can do the routing instead. This article explains how device-based redirection actually works under the bonnet, where it overlaps with Apple's own Smart App Banners and Android's App Links (and where it very much does not), why a tool many agencies used for exactly this job disappeared in 2025, and how to set the whole thing up with a dynamic QR code without writing a full app-linking stack yourself.

Why agencies end up printing two QR codes for one app

The App Store and Google Play are separate systems with separate URL formats. An App Store listing lives at a URL like apps.apple.com/us/app/instagram/id389801252; a Google Play listing lives at play.google.com/store/apps/details?id=com.instagram.android. Neither Apple nor Google publishes a single "smart" URL that resolves to the correct store depending on who is asking. That gap is real, not an oversight either company forgot to close, and it is the entire reason a market of link-redirection tools exists to fill it.

A QR code itself has no opinion about this. It just encodes a URL, and a scanner opens that URL. The intelligence has to live somewhere else: at the URL the code points to. That is the whole trick, and it is worth being precise about it, because "smart QR code" gets thrown around as if the code itself is doing something clever. It isn't. The code is static data. The redirect it points to is what decides where the visitor ends up, and that decision is made by reading a single HTTP header.

How device-based QR redirection actually works

When a phone requests a web page, it sends a User-Agent header identifying the browser and, usually, the operating system. A redirect service reads that header on the server side, before rendering anything, and sends a 301 or 302 redirect to the right destination. iPhones and iPads report strings containing "iPhone" or "iPad"; Android devices report "Android". A server-side rule as simple as "if the UA contains iPhone or iPad, redirect to the App Store URL; if it contains Android, redirect to the Play Store URL; otherwise, redirect to a normal web landing page" is genuinely most of the implementation.

There is no published specification from Apple, Google or the W3C that defines these substring patterns as a contract you can rely on forever. It is observed, stable, widely-used practice, not an API. In practice it has stayed reliable for years because both companies have strong incentives to keep their own browsers identifiable (app compatibility across the web depends on it), but it is worth building the fallback path properly rather than assuming detection will always be perfect.

What the User-Agent header tells the redirect, and what it doesn't

The header tells you platform family (iOS-ish vs Android vs neither) reliably. It tells you exact OS version much less reliably today. Apple has been progressively freezing the amount of detail Safari's User-Agent string reveals since Safari 11.1, and continued that trend with iOS 26, reporting a static, less specific OS version string as a privacy measure. That does not break the iPhone-vs-Android distinction your redirect needs, because the platform token itself doesn't change, but it means you should not design anything that depends on knowing precisely which iOS version someone is running from the header alone.

The header can also be spoofed, stripped, or altered by privacy-focused browsers and browser extensions. This is not a reason to avoid the pattern (it is standard practice across the entire link-in-bio and app-marketing industry) but it is a reason to keep the fallback destination genuinely useful rather than a dead end, since a small percentage of visitors will land there by accident.

What happens on desktop or an unrecognised device

This is the part vendor pages routinely skip, and it is the part that actually determines whether the campaign works. A QR code printed on packaging, a flyer, or a shop window will occasionally get scanned from a laptop camera, an iPad in desktop mode, or a scanner app that strips identifying headers. Route that traffic to a store badge and it dead-ends: there is no "App Store" on a desktop browser. The fallback should be a normal web page, ideally the app's marketing page with both store badges rendered as ordinary links, so nobody hits a wall. Building that fallback page takes ten minutes and turns an edge case into a non-issue.

Why this isn't the same as Apple's Smart App Banner

Apple already has a mechanism for promoting an app to Safari visitors: the Smart App Banner, added with a single meta tag, <meta name="apple-itunes-app" content="app-id=YOUR_ID, app-argument=YOUR_URL">, placed in the page head. It is genuinely useful, and it is still fully supported. But it solves a different problem to the one this article is about, and mixing the two up leads to broken setups.

The Smart App Banner only appears when Safari actually renders the tagged page and a visitor lingers on it. It does not fire inside an in-app browser (the webview Instagram, TikTok or Facebook opens links in), it does not fire in an iframe, and critically for QR campaigns, it never gets a chance to fire if your redirect immediately bounces the visitor onward with a server-side 301 before Safari finishes loading the page. A QR code that redirects straight to the App Store never shows Safari the tagged page at all, so the banner is structurally irrelevant to that flow. The banner is for a different journey: someone browsing your website directly in Safari and choosing to stay there for a moment. Device-based QR redirection is for someone who scanned a code with a single, explicit intent (get the app) and should be sent straight there.

The Firebase Dynamic Links gap agencies are still feeling

If your agency built app-install QR flows any time in the last decade, there is a fair chance you used Firebase Dynamic Links to do exactly this kind of routing. Google announced its deprecation in August 2023, made the console read-only from 24 May 2024, and shut the service down completely on 25 August 2025: every page.link and custom Dynamic Links domain now returns nothing. Google's stated reasoning was that the native alternatives (Universal Links, App Links, and newer mechanisms) had matured enough that a dedicated cross-platform smart-link product was no longer necessary.

That leaves a genuine hole for agencies who relied on it, and it is a large part of why this is worth solving properly now rather than reaching for whatever half-finished script still works. A dynamic QR code pointed at a redirect endpoint you control sidesteps the dependency entirely: you are not relying on a third-party smart-link product's continued existence, you are relying on a URL you own doing one simple job.

Universal Links and App Links: routing people who already have the app

Everything above is about getting someone who does not have the app yet to the right store listing. A separate, related mechanism handles the case where the app is already installed: Universal Links on iOS and App Links on Android let a URL open directly inside the installed app instead of a browser, skipping the store entirely. These rely on a verification file (apple-app-site-association for iOS, a Digital Asset Links file for Android) hosted on your domain, and Apple's own documentation is explicit that Universal Links do not support being reached via a server-side redirect for the verification step, so they need to be configured directly on the domain the QR code points to if you want that behaviour for returning users.

For a QR-code campaign the practical takeaway is simpler than the full deep-linking spec: if the goal is new installs, device-based redirection to the correct store listing is the right tool. If a meaningful share of scans will come from people who already have the app (a loyalty card reprint, a repeat customer flyer), it is worth layering Universal Links or App Links on top so those visitors skip the store and land inside the app itself, rather than being sent to a listing they've already got.

1. Scan. The camera opens the QR code's URL, exactly like tapping any link.
2. Check. The redirect endpoint reads the visitor's User-Agent header before rendering anything.
3. iPhone or iPad. Redirected straight to the App Store listing.
4. Android. Redirected straight to the Google Play listing.
5. Anything else. Desktop, tablet, or an unrecognised device gets the web fallback page instead of a dead end.

Setting this up with a dynamic QR code

The QR code itself only needs to point at one thing: a URL that does the device detection. You do not print a different code for iOS and Android, and you do not need the code to encode any special logic, because a QR code cannot run code. What changes is what sits behind the destination URL.

Two workable approaches:

• Use a redirect service or a small serverless function you control, one that reads the incoming User-Agent header and 301s to the correct store URL, with a proper web-page fallback for anything else. This is a genuinely small piece of code (the entire logic fits in a dozen lines), and owning it means you are not exposed to another vendor shutting the service down the way Firebase Dynamic Links did.
• Point the QR code's destination at that endpoint using a dynamic QR code rather than baking the URL directly into the printed code. See dynamic vs static QR codes for the full picture. This is the detail that actually matters for an agency managing a client relationship: the printed code never has to change, but the endpoint behind it can. If the client redesigns their app-store listing, moves to a new redirect provider, or the campaign shifts from "download the app" to "check out our new feature", you change the destination without reprinting anything.

That second point is where a dynamic QR platform earns its keep on an app-install campaign specifically. Print runs for packaging, till-point stickers, or in-store signage are expensive and slow to replace. A code that can be repointed the moment the redirect logic needs updating, without touching the physical asset, is the difference between a six-week reprint cycle and a five-minute fix.

It is also worth tracking the split once the campaign is live. A scan doesn't tell you whether it converted into an install, but it does tell you the device breakdown of who scanned, which is useful for reporting back to a client who wants to know whether their iPhone-heavy or Android-heavy audience actually matches the campaign's targeting assumptions. If your QR analytics captures device type per scan, that split is sitting in the data without any extra setup.

Does device detection need a cookie banner?

Reading a User-Agent header to decide which store to redirect to does not, by itself, set a cookie, store anything on the visitor's device, or require consent under the ePrivacy rules that govern cookies and local storage. It is a server reading a header the browser sends on every request anyway, and using it once to pick a redirect target.

Whether the User-Agent string itself counts as personal data under GDPR is a slightly different question, and the honest answer is that it depends on context rather than being a flat yes or no. Regulatory guidance (the UK ICO's work on adtech and real-time bidding, for instance) treats device and browser identifiers as personal data when they can be used, alone or combined with other signals, to single out an individual. A one-off UA read used purely to choose between two public store URLs, with nothing logged against an identifiable person, sits at the low-risk end of that spectrum, but if you are also logging the full UA string alongside IP addresses and building profiles over time, that is a different, higher-risk use and should be treated as such in your privacy documentation. For the wider picture of what a QR scan does and doesn't collect, see the GDPR compliance rundown.

Frequently asked questions

Can one QR code go to both the App Store and Google Play?

Yes. The QR code itself always points at the same single URL. That URL leads to a redirect step that reads the visitor's device and sends iPhone and iPad visitors to the App Store, Android visitors to Google Play, and everyone else to a normal web landing page with both store badges.

How does a QR code know if I'm on an iPhone or Android?

It doesn't, the QR code has no logic of its own. The redirect endpoint the code points to reads the User-Agent HTTP header your browser sends automatically, checks it for platform indicators such as "iPhone", "iPad" or "Android", and redirects accordingly. This happens before any page content loads.

What happens when someone scans an app-store QR code on a desktop?

If the redirect logic is built properly, they land on a normal web page, typically the app's marketing page with both store badges shown as ordinary links, rather than being sent to a store listing that doesn't exist for their device. A poorly built redirect that only handles iOS and Android and has no fallback will dead-end desktop and tablet visitors, so this fallback is worth testing explicitly before a campaign goes live.

Is a "smart" QR code different from a regular dynamic QR code?

Not structurally. Both are QR codes pointing at a URL that can be changed after printing. What makes a QR code feel "smart" is the redirect logic sitting behind that URL (device detection, in this case), not anything different about the code itself.

Can a QR code open an app directly if it's already installed, rather than going to the store?

Yes, but that's a different mechanism: Universal Links on iOS and App Links on Android, which route straight into an installed app using a verification file hosted on the destination domain. Device-based store redirection and Universal/App Links solve related but separate problems, and a mature setup often uses both: Universal/App Links for people who already have the app, store redirection for people who don't.

How fast is device detection when someone scans the code?

It happens as part of the normal HTTP redirect, typically well under a second on modern edge/serverless infrastructure, and is not perceptible to the person scanning as a separate step.

Does device-based redirection collect personal data or need a GDPR cookie banner?

Reading a User-Agent header to pick a redirect target does not itself set a cookie or require consent under ePrivacy cookie rules. Whether the UA string counts as personal data depends on what else you do with it. A one-off read used only to choose a redirect target, with no profile built over time, is low-risk; logging it alongside other identifiers for tracking is a different, higher-risk case.

Do native camera scanners handle redirects differently from third-party scanner apps?

Not meaningfully for this use case. Both iOS's native Camera app scanner and Android's native scanner (via Google Lens or the camera app) simply open the resolved URL in the default browser, following any server-side redirect exactly as a normal link tap would. Older or unusual third-party scanner apps occasionally strip or alter headers, which is one more reason to keep the fallback page genuinely useful.

Can I see how many scans came from iOS versus Android?

If the QR platform records device type per scan (most dynamic QR tools do, since they read the same User-Agent header for their own analytics), yes, that split is available in the scan data without any extra configuration on the redirect side.

What replaced Firebase Dynamic Links after it shut down?

Google's own guidance points to the native platform mechanisms: Universal Links and App Links for deep linking into installed apps, plus standard device-based redirect logic (the pattern this article describes) for new-install flows, rather than a single drop-in replacement product.

The short version

A QR code cannot branch by device on its own, it just points at a URL. Put a small piece of redirect logic behind that URL that reads the visitor's User-Agent header, and one printed code can send iPhone users to the App Store, Android users to Google Play, and everyone else to a proper web fallback, no dead ends. Keep that redirect logic separate from the printed code by using a dynamic QR code, so a change to the app listing, the redirect provider, or the campaign itself never means reprinting anything. If your agency used Firebase Dynamic Links for this before its 2025 shutdown, this is the durable replacement pattern: own the redirect, point a dynamic code at it, and check the device split in your scan analytics once it's live.