What you are seeing
This fix makes the code work on iPhone without breaking Android. You will verify the iPhone camera setup, rebuild the payload in the most standard format, and confirm the full action on iPhone. Test on two iPhones if you can, because one phone's settings can mislead you. Keep Android passing at every step.
Likely causes
1.
Payload shape iPhone rejects — Quick test: decode the payload and compare its layout with the standard format for that type.
2.
iPhone Scan QR Codes setting switched off — Quick test: check the iPhone camera settings for the QR scanning option.
3.
Action iPhone will not perform automatically — Quick test: check whether the preview banner appears even though the action fails.
4.
Encoding or special characters — Quick test: decode on both platforms and compare the text character by character.
5.
Focus, distance, or lens issue on that iPhone — Quick test: try the same iPhone on other codes and at a different distance.
Step-by-step fix
Step 1: On the failing iPhone, check that QR scanning is enabled in the camera settings and clean the lens.
Step 2: Point the iPhone camera at a known-good code. If that also fails, the phone setup is the problem, not your code.
Step 3: Decode your payload and rebuild it with the matching generator in the standard format.
Step 4: Simplify special characters and unusual fields, then print a fresh proof.
Step 5: Test the proof on two iPhones, watching both the preview banner and the action that follows.
Step 6: Add a short typed fallback beside the code so iPhone users can complete the action manually.
Step 7: Retest the final proof on Android and on both iPhones, and keep the version that passes everywhere.
Putting this into practice
In practice, keep one iPhone in your test kit even if your team mostly uses Android. Cross-platform codes fail in exactly the gap between the two test setups, and one device on each side closes it. Record the before-and-after behaviour with the job file, so the fix is provable rather than anecdotal. When the same failure appears again, that record tells you whether the old fix held or a new cause appeared.
Common mistakes to avoid
- Assuming every iPhone behaves identically, when settings, iOS version, and lens condition all vary.
- 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 on Android but not iPhone will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that scans on Android but not iPhone.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- iPhone camera scanning is enabled on the test phone
- The payload uses the standard format for its type
- The code scans and completes its action on two iPhones
- 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
- [QR payload inspector](/qr-payload-inspector)
- [QR offline verifier](/qr-offline-verifier)
- [QR scanner](/qr-scanner)
- [QR size calculator](/qr-size-calculator)
- [QR safety checker](/qr-safety-checker)
- [blog](/blog)
