1. The Problem with Custom URI Schemes
Early deep links used custom URI schemes (`myapp://product/123`). If the app is not installed, the OS shows an error dialog. QR codes encoding custom schemes create a poor experience for users who have not yet installed the app.
2. iOS Universal Links
Universal Links use a standard HTTPS URL. Apple retrieves the AASA (Apple App Site Association) file from your domain (`/.well-known/apple-app-site-association`) at first link activation and verifies the association between the domain and your app ID. Subsequent scans of the QR open the app directly if installed, and the web page if not.
```json
{
"applinks": {
"details": [{
"appIDs": ["TEAMID.com.example.app"],
"components": [{ "/": "/product/*" }]
}]
}
}
```
3. Android App Links
Android App Links use the `.well-known/assetlinks.json` file on your domain to verify the association with your app's package name and signing key. Verified App Links open the app directly without an intent disambiguation dialog.
4. The Fallback Strategy
Your QR should always encode an HTTPS URL that:
1. Attempts to route to the app via Universal Link or App Link.
2. Falls back to a mobile-optimised web page with a smart app banner (iOS) or Play Store / App Store download prompt.
3. Works fully as a web experience for users who will never install the app.
5. Branch.io and Firebase Dynamic Links
Third-party deep link platforms (Branch, Adjust, Firebase Dynamic Links — note: Firebase Dynamic Links deprecated in 2025, migrate to Branch or alternatives) handle cross-platform routing, attribution, and deferred deep linking (the user installs the app after scanning, and the app opens to the specific content on first launch).
Putting this into practice
Start with the smallest real test you can run. Generate the code, print it at the exact size you plan to use, and scan it with two different phones in the lighting where it will live. Check that the destination page loads quickly on a mobile connection and that the call to action next to the code tells people what they will get. If anything feels slow or unclear, fix it before you print a full batch, because reprints cost more than a short test. Keep a note of the size, material, and placement that worked so the next batch starts from a proven setup.
Common mistakes to avoid
The most common mistakes are easy to avoid once you know them. Long payloads make modules tiny, low contrast makes edges hard to read, and text placed too close to the border eats the quiet zone the scanner needs. Covering a corner finder pattern with a logo or a sticker breaks detection entirely, and a code placed behind glare or on a curved surface fails even when the print is perfect. Review each of these points on a proof copy, and treat any failure as a reason to adjust the design rather than a reason to blame the scanner.
Quick checklist
- Keep the payload as short as practical so modules stay large.
- Keep dark modules on a light background with strong contrast.
- Leave a clear quiet zone on all four sides of the symbol.
- Test the printed code at the real viewing distance and lighting.
- Confirm the destination page loads fast on a phone.
- Recheck the code after any change to the link, design, or placement.
Related tools and guides
- Use the [QR size calculator](/qr-size-calculator) to match the printed size to the expected scan distance before you commit to a print run.
- The [error correction simulator](/error-correction-simulator) shows how damage tolerance changes the density of the symbol at each level.
- Test every code with the [QR scanner](/qr-scanner) on more than one phone before you publish or print it.
- Create a fresh code with the [URL QR code generator](/url-qr-code-generator) when the destination is a web page.
- Run unfamiliar destinations through the [QR safety checker](/qr-safety-checker) before you share a code widely.
- The [blog](/blog) collects more guides on sizing, printing, security, and payments for QR codes.
