How Do I Make One QR Code That Opens the App Store or Google Play Depending on the Phone?
Use a dynamic QR code with device routing: the redirect reads the phone's user agent and sends iPhones to the App Store and Android phones to Google Play.
Nookesh Karri · 6 min read 
Use a dynamic QR code with device-based routing. The code holds one short link, and when someone scans it, the redirect server checks what phone made the request: iPhones go to your App Store listing, Android phones go to Google Play, and anything else goes to a fallback page. You give it the two store links once and print one code.
A static code can’t do this. It holds one fixed URL.
What you need
- Your Google Play link. Google’s linking guide gives the format:
https://play.google.com/store/apps/details?id=<package_name>. The package name is declared in the app’s manifest file and is also shown in the Google Play Console. Google Maps, for example, usescom.google.android.apps.maps. - Your App Store link. Use the standard link with your app’s numeric ID, the one you get from the “Share” option on your App Store listing.
- A fallback page. A simple web page with both store badges, for desktops, tablets and anything the router can’t classify.
- A QR generator that supports device routing.
Step by step
- Copy both store links and open each one on a phone to check it lands on the right listing.
- Create a dynamic QR code and set the main destination to your fallback page.
- Turn on device routing. Paste the App Store link as the iOS destination and the Google Play link as the Android destination.
- Add a short call to action next to the code, such as “Scan to get the app”.
- Download the code as an SVG for print.
- Scan it with an iPhone, an Android phone, and a laptop or tablet camera. You should get three different pages.
QRAnalytica has this built in: iOS goes to the App Store, Android to Google Play, everyone else to a desktop landing page. Set it up in the dynamic QR code generator.
How the routing works
When a phone opens a link, its browser sends a header called User-Agent with the request. MDN describes it as “a characteristic string that lets servers and network peers identify the application, operating system, vendor, and/or version of the requesting user agent.” The redirect server reads the operating system from that string and picks the matching store.
The printed pattern holds only the short redirect link. The two store URLs, the fallback and any later changes live on the server. Dynamic vs static QR codes covers the trade-off.
Don’t use the short links Apple made for print
Apple once offered App Store Short Links on appstore.com, built from your app or company name. Its Technical Q&A QA1633 even pitched them for “offline communications materials like print ads, TV spots, app trailers, radio ads and billboards.” The same page also warns they “are not guaranteed to link to a particular app or company.” Its advice: “always use these standard links when driving users to your app from your digital marketing communications.”
The routing link is already short. A name-based link that might open the wrong app buys you nothing.
A real example of what goes wrong: Firebase Dynamic Links
Many apps used Firebase Dynamic Links for exactly this: one link, the right store per platform. Google retired it. The Firebase deprecation FAQ says, “On August 25th, 2025, Firebase Dynamic Links will shut down,” and that afterwards “All links clicked will return a HTTP 404 status response to end users.”
Anyone who printed those links on packaging, posters or flyers lost them overnight. Put a redirect you control in front of the store links so you can swap what sits behind it. It’s the same reason people change a QR code’s destination after printing instead of reprinting.
My take
Point the default destination at a landing page with both store badges. Never at one of the stores. When detection misses, the landing page still works for everyone. Sending unknown devices to the App Store means some Android users land on a listing they can’t install from, and they won’t try twice.
The limitation: device detection is a guess
MDN’s guide on browser detection says reading the user agent string “is very hard to do reliably, and is often a cause of bugs.” It also warns never to use the operating system alone to tell phones from tablets, because Android runs on tablets as well as phones.
iPhones and Android phones are easy to tell apart, and that’s the split app stores need. Tablets, in-app browsers and unusual phones are where it breaks. That’s what the fallback page catches.
There’s also the dependency. QRAnalytica’s dynamic codes run through its redirect servers, which is what makes routing, editing and scan counts possible. Codes keep working if your subscription or trial ends, but a service still sits between the print and the store.
How to check it worked
- iPhone scan: your App Store listing opens.
- An Android phone should open Google Play on your listing.
- On a laptop, the link shows the fallback page.
After launch, compare scan counts by device with installs from each store. To separate campaigns, add tracking parameters to the fallback page link (UTM parameters for QR codes covers how). How to track QR code scans explains what the scan numbers can and can’t tell you.
FAQ
Can a static QR code send iPhones and Android phones to different stores?
No. A static code holds one fixed URL, and every phone opens the same link. Splitting by phone needs a server in the middle that looks at the request and picks the store, which is what a dynamic code with device routing does.
How does the QR code know which phone scanned it?
When the phone opens the link, its browser sends a User-Agent header that names the operating system. The redirect server reads that header and sends iPhones to the App Store link and Android phones to the Google Play link.
What happens if someone scans it on a computer or a tablet?
That depends on your fallback. Set a fallback URL, such as a landing page with both store badges, so anything that isn’t clearly an iPhone or Android phone still lands somewhere useful.
Can I just use an appstore.com short link?
Apple’s own guidance says those short links are a convenience and are not guaranteed to point to a particular app. It recommends the standard links that contain your app’s numerical ID for marketing.
Is Firebase Dynamic Links still an option?
No. Google’s FAQ says Firebase Dynamic Links shut down on August 25th, 2025, and links now return a 404 error to people who click them.