What you are seeing
The code scans, but the app it should open does not launch: nothing happens, a browser page opens instead, or an error appears. The scan worked, so the fault sits in the app handover: the link, the app association, or the fallback behaviour. App links depend on the phone, the app, and the site working together, so a code that opens an app on one phone can fail on another. The fix is to trace the handover and to make sure visitors who lack the app still reach something useful.
Likely causes
1.
Link points at the app, not the content — A link that targets the app directly can fail on phones without the app, instead of falling back to a web page. Test: open the link on a phone without the app.
2.
App link association not set up — An app link that is not correctly associated with the domain opens in the browser instead of the app. Test: check the app link setup for the domain.
3.
App not installed on the phone — A phone without the app cannot open it, and a code with no fallback leaves the visitor stranded. Test: check whether the app is installed on the failing phone.
4.
Redirect breaks the app link — A redirect can strip the app link information, so the phone treats the destination as an ordinary web page. Test: follow the redirect chain and compare the app behaviour.
5.
Link mistyped or outdated — A mistyped link or a link to a removed app page can fail to open anything. Test: decode the payload and compare the link with the intended app page.
Step-by-step fix
1. Decode the payload and write down the exact link it carries.
2. Test the link on a phone with the app and on a phone without it.
3. Check the app link association for the domain.
4. Fix the link, the redirect, or the app link setup, whichever breaks the handover.
5. Add a web fallback page so visitors without the app still reach the content.
6. Retest on two phones, with and without the app.
Putting this into practice
In practice, the fallback is the fix that matters most. Most visitors who scan a code do not have your app installed, so a code that only works with the app fails for most of its audience. Point the code at a page that offers the app and the content, and let the phone choose. Keep a short note of what you tested, what failed, and what you changed, so the next person starts from evidence rather than guesswork. A fix that is written down survives staff changes and reprints; a fix that lives only in memory gets repeated.
Common mistakes to avoid
- Pointing a public QR code at an app-only link with no web fallback for visitors who lack the app.
- Reprinting the full run before a single proof passes, which turns one failure into many.
- Testing on one phone in ideal conditions instead of two phones in the real conditions where a code that scans but the app will not open will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that scans but the app will not open.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The link opens the app where the app is installed
- Visitors without the app reach a useful web page
- The journey passes on two phones, with and without the app
- The corrected proof passes on two phones in the real conditions
- The fix is recorded in the job file so the next reprint starts from a proven setup
- Every printed copy is checked against the approved proof
- The proof is retested after any later change to the link, design, or placement
Related tools and guides
- [app store QR code generator](/app-store-qr-code-generator)
- [QR payload inspector](/qr-payload-inspector)
- [QR redirect chain viewer](/qr-redirect-chain-viewer)
- [QR expiry checker](/qr-expiry-checker)
- [QR scan log](/qr-scan-log)
- [QR safety checker](/qr-safety-checker)
