One QR code for the App Store and Google Play

01

What happens when someone scans it

The printed code holds a short Mosaqo address, not a store link. When a phone opens it, the redirect reads the operating system the browser reports and answers with the link you gave for that system: the iPhone link for an iPhone, the Android link for an Android phone. Anything else — a laptop, a tablet asking for the desktop site, a phone you gave no link for — goes to the web fallback.

A phone without a link of its own goes to the web page, never to the other platform’s store. An Android phone sent to the App Store is a dead end; a web page with both store badges on it is not.

• iPhone: the App Store link, or a universal link that opens the app when it is installed
• Android: the Google Play link, or an Android app link
• Everything else: the web fallback, which every app link must have
• The choice is made on each scan, so it is right for whoever is holding the phone

02

Store links, universal links, and why myapp:// does not work here

Each phone link has to be an https address, because a scan is a redirect and a redirect can only hand the browser a web address. A store page is one. So is a universal link on iOS or an app link on Android: the operating system opens the app if it is installed and the web page if it is not. That part is the phone’s behaviour, not the code’s.

A custom scheme such as myapp:// is not a web address, so the editor refuses it in a dynamic code rather than accepting it and quietly sending everyone to the fallback. If you want the app to open for people who already have it, use the universal or app link your developers publish. If the goal is installs, the store link is the safer choice: the store page itself offers to open the app for someone who already has it.

03

Why it has to be a dynamic code

A static code is the link itself, written into the pattern. It holds one address for every phone, so it cannot tell an iPhone from an Android phone: Mosaqo writes the iPhone link into it if there is one, which is the wrong answer for every Android user. The editor says so when you choose static.

A dynamic code keeps every link editable, and that matters more for an app than for most destinations. Store addresses change when an app is renamed or moves to another developer account, and the launch-week campaign page is not the page you want people to land on six months later.

• Change any of the three links after printing; the printed pattern stays the same
• Every change is a new revision, and an earlier one can be restored
• Redirect rules you add in the web editor still come first — a launch page for a fixed window, another store link for one country

04

What the numbers tell you, and what they do not

Every scan of a published code is recorded with the operating system and device the browser reported, the country and the time. That is enough to see the split between iPhone and Android scans, which placement drew them, and whether the poster in the window is earning its space. Scans made during the publish checklist’s test window are kept out of the totals, and known bots are filtered out by default.

A scan is not an install. The redirect sees the scan; it does not see what happens in the store afterwards. If you need installs per placement, use the campaign links that App Store Connect and Google Play Console let you build as the phone links — a separate code for each placement, a separate campaign link for each code — and read the installs there.

• Scans by operating system, device, country and day
• Unique scans, counted per device and network each day rather than per person
• Scan records are kept for 90 days by default, and the workspace settings can change that
• Installs and app opens are measured in the stores, not here

05

Where to print it, and how to test it first

Put the code where people have a minute and a reason to install: packaging and inserts, receipts, table cards, posters by the till, event badges, the back of a business card. Say what the scan does next to it. “Scan to get the app” is a promise a person can decide on; a bare code is not.

Before the print run, scan the code with an iPhone, an Android phone and a laptop, and check that each one lands where you meant it to. The publish checklist opens a short test window for exactly this, and those scans are not counted.

• Give each placement its own code if you want to compare them later
• Make the fallback page worth landing on: both store badges and a line about the app
• Check size and contrast against the print guidelines before you order