Direct App Store listing
A plain iOS listing address. Short, sparse, and correct for packaging aimed exclusively at iPhone users.
Encoded as
https://apps.apple.com/app/id123456789Point people at your store listing, with a clear-eyed view of the two-platform problem.
Generated on your device. Nothing you type is sent anywhere.
An app download QR code opens your listing in the App Store or on Google Play. There is an inherent problem with this format that most tools skate over, and it is worth stating plainly: a static code contains one address, while your users are on two different platforms. A code pointing at the App Store is useless to an Android user and vice versa. There are three honest ways to handle that, and choosing between them is the real decision here — not anything about the code itself.
Searching an app store by name returns competitors, clones and unrelated results, and users routinely install the wrong thing. A code goes directly to your listing, which removes both the friction and the misinstalls.
Someone holding your product or standing at your counter is at their most willing to install. A code converts that moment immediately rather than depending on them remembering to look later, which mostly does not happen.
A plain store listing address is short enough to produce a coarse pattern, so it prints small on a box or a card without becoming difficult to scan.
Pointing at your own page rather than directly at a store means you can change store links, add a web fallback, or redirect entirely without reprinting anything.
A plain iOS listing address. Short, sparse, and correct for packaging aimed exclusively at iPhone users.
Encoded as
https://apps.apple.com/app/id123456789The Android equivalent, using the package name. Slightly longer than the Apple form but still comfortably sparse.
Encoded as
https://play.google.com/store/apps/details?id=com.example.appThe recommended approach for a mixed audience — one code, a page you control, and both store links behind it.
Encoded as
https://example.com/appTake the public address of your app from the App Store or Google Play and paste it into Store listing link. Use the plain listing address rather than a campaign-tagged link, which is considerably longer.
Either print two codes labelled by platform, or point one code at a page on your own site that offers both. The second option keeps a single code and lets you change the destinations later.
Store links with attribution tags attached can be very long, which makes the pattern dense. If you need attribution, a short redirect on your own domain keeps the printed code sparse.
Test on an iPhone and an Android handset. A landing page that detects platform badly is worse than two clearly labelled codes, and you only find that out by trying both.
A static QR contains exactly one address. Pointing it at the App Store strands every Android user and vice versa. No generator can change this, and services that appear to are running a redirect on their own servers that inspects the device — which works, but makes your printed codes depend on that company continuing to exist.
Redirect services that detect the platform solve the problem elegantly until they shut down, change pricing or start showing an interstitial. Every printed code fails at once when that happens. A page on your own domain does the same job with no external dependency.
Attribution parameters on store links can more than double the address length, producing a much denser pattern. On packaging that can be the difference between scanning and not. Use a short redirect on your own domain and apply the tagging server-side.
Someone unwilling to install anything hits a dead end at a store page. If the underlying task can be done on the web, a landing page offering both the app and a browser option converts considerably better than a store link alone.
Store URLs change when an app is removed, republished under a new identifier, or moved between developer accounts. Codes pointing directly at a store then break permanently, where a code pointing at your own page can simply be redirected.
The payload is a standard https link, so every scanner opens it. An App Store link on an iPhone opens the App Store app directly; on Android it opens a web page showing an iOS app the person cannot install, which is confusing rather than merely unhelpful. Google Play links behave the same way in reverse. Desktop scans open the web version of the store listing, which is useful for checking but cannot install anything. This asymmetry is the entire reason the landing page approach is usually the better answer for any audience that is not exclusively on one platform.
Because the whole payload is a single URL, the value passes through without percent-encoding — encoding it would break the address. Google Play links carry their package identifier in a query parameter, which makes them slightly longer than the Apple equivalent.
Not on its own. A static code contains one address, and store links are platform-specific. The two honest solutions are printing two labelled codes, or pointing one code at a page on your own site that offers both. Services that appear to do this automatically are running a redirect that inspects the device, which works but makes your codes dependent on them.
They solve the problem neatly, but they place a third party between your printed code and your app. If that service closes, changes pricing or adds an interstitial page, every code you have printed is affected at once. A page on your own domain does the same job and cannot be withdrawn by anybody else.
Campaign and attribution parameters, almost always. They can more than double the length of a store address, and the pattern grows accordingly. Use a short address on your own domain that redirects, and apply the tagging server-side where it costs you nothing in printed size.
They land on a web page showing an iOS app they cannot install. It is actively confusing rather than simply unhelpful, because the page looks legitimate and gives no clear indication of what went wrong. This is the main argument for labelling platform-specific codes clearly.
Where the task can be done in a browser, yes. A meaningful proportion of people will not install an app for a one-off interaction such as paying for parking or viewing a menu. A landing page offering both routes converts better than a store link that presents installation as the only option.
No. The code is generated in your browser from the address you type, and nothing is transmitted at any point. There is also no redirect service in the middle, so nothing here can break, expire or start charging for the codes you print.
This generator is part of website & links QR codes — see the whole group, and what to decide before you generate one.