One code, two stores
One QR code that sends every phone to the right app store
A single store link is the wrong link for roughly half the people who scan it, and a printed code cannot be reprinted to fix that. One link, two rules on operating system, and the phone decides: an iPhone gets the App Store, an Android gets Google Play, and anything else gets your web page.
The rule
Two rules and a fall-through
This is the whole configuration. Rules are evaluated in order and the first one that matches wins, which matters more than it looks: a rule on device and a rule on operating system will both match an iPhone, so the order is the answer rather than a tie-break.
| When | Send them to | Why |
|---|---|---|
| os is iOS | Your App Store listing | iPadOS matches this too. Treating an iPad as its own platform is how every iPad quietly ends up on the desktop site. |
| os is Android | Your Google Play listing | Checked after iOS only because the list is ordered; the two cannot both match. |
| Everything else | The link’s own destination | Not a rule. A laptop, a games console, a phone nobody anticipated — all fall through to wherever the link itself points, which is a working page. |
Rules can go further than this where you need them to. They also match browser, country, continent, region, city and the language a phone is set to, and they combine — which is how one code sends an iPhone in the US to the US listing and an iPhone in the UK to the UK one. The other jobs this covers.
Deep linking
Opening the app itself: available on demand
Two different things get sold under one heading, and the difference only shows up after the artwork is at the printer — so it is worth being exact about which one you get today and which one to ask us for.
What is on the shelf is store routing: read the operating system, send the phone to the right listing. For turning a printed code into an install, that is the entire job, and it is the case this routing was designed around.
What you can ask for is the other half — the link opening your app directly on a phone that already has it, rather than bouncing through a store page the person does not need. That is Universal Links on iOS and App Links on Android, and it is a genuinely different mechanism: a phone only lets a link open an app when the domain the link sits on publishes a file naming that app. Those files are domain-wide, so on a short domain shared between customers there is one set for everybody — yours has to sit on a short domain of your own. We have kept both paths reserved from the beginning so that when your domain arrives, nothing has been squatted on it.
It is two pieces, then: a short domain of your own, and a small amount of configuration at each end — your team identifier and package name on one side, the association files served on ours. That is why it is scoped with you rather than switched on in a settings page, and why we would rather you asked than guessed.
Want your links to open your app?
Tell us the app and the domain you would want the links on, and we will scope it with you. Deep linking is arranged directly rather than self-serve, and it goes out alongside custom domains.
Why it has to be one code
The artwork is the part that cannot be changed
Everything downstream of a print run is editable. The run itself is not.
The alternative to routing is printing two codes with two captions, which asks a stranger holding a box in a shop to know which operating system they are on and choose correctly. Most of the ones who guess wrong do not try again.
The other alternative is one store link and a note saying “also on Android”, which is the same problem with worse manners.
One code, routed, also stays fixable. When the listing moves, the app is renamed, or the campaign behind it ends, you edit the destination and every code already printed starts going somewhere else. The address in the pattern never changes — only where it lands.
What comes back
What you can tell afterwards
A store listing reports installs and tells you nothing about where they came from. This is the half in front of the store.
Scans, apart from clicks
A scan of the printed code and a click on the same link posted online are counted separately, so “did the packaging work?” is a question with an answer rather than a share of one total.
Which store each visitor was sent to
Device and operating system are on every recorded visit, so the split between iOS and Android is readable from the report — including the visitors who matched no rule and went to the web page.
The scanner traffic taken out
A code in an email footer or a PDF gets opened by mail-security scanners before any recipient sees it. Those are separated out and named rather than folded into the total.
What it will not tell you is which scans became installs or purchases — that is conversion attribution, and it is not built. How a click is counted covers what is separated out of the totals, and why.
Build one and scan it yourself
Ten links free, with the whole report from the first scan. Point one at both your store listings, download the code as SVG, and check it on the two phones nearest you before it goes anywhere near a printer.