QR code not working on iPhone

A QR code not working on iPhone is usually the print or a Camera restriction, not a missing app. iOS Camera reads a well-formed symbol from the viewfinder. Screen Time camera block, weak contrast, motion blur, and a hop that never 302s are the usual causes. Confirm each fix with a test scan on a second iPhone.

Why a QR code not working on iPhone is often the file

Guests blame the phone because the same JPEG looked fine on a laptop. iOS Camera still needs dark finder squares on a light field, modules large enough at the standing distance, and a quiet zone the crop did not eat. A website URL code that fails only in Camera, then opens if you type the URL, is a print problem.

The iOS Camera banner is the success signal. If it never appears, stop debugging Safari. If it appears and Safari errors, the pattern worked and the destination did not.

Do not screenshot the on-screen preview. That raster encodes /qr-preview. Send SVG or a high-resolution PNG of the final millimetres to the printer, then scan the press proof.

A free static generator such as the iOS one-off tools is enough when the payload will never move and you will never count scans. Use a hosted hop when guest-room URLs will change.

Screen Time camera block

Cause: the test iPhone has Camera limited under Screen Time, or a managed guest device disables the viewfinder features staff use on their own phones. The poster is innocent. The handset never offers the iOS Camera banner.

Fix: scan with a personal iPhone that has Camera allowed. Control Centre still will not help if Camera itself is restricted. Do not promise a specific lock-screen scan UI; that behaviour varies by version.

Confirm: the same printed card on an unrestricted iPhone should show the banner within a second at about 30 cm for a 2 cm symbol. If it does, brief staff that some guest handsets will not scan, and put a short URL next to the code for those cases.

iOS Camera needs dark finders on a light patch

Cause: the art is light modules on a dark menu, a slate table, or a navy wrap, without a true invert the reader can renormalise. iPhone is strict about finder contrast. A design that "looks branded" on screen is unread under a downlighter.

Fix: print dark modules on a solid light patch, then put brand colour around it. If you invert, the finders must still read as the camera expects. Transparent stickers on glass pick up the street as the light modules; back the symbol with white.

Confirm: scan in the real lighting, not at a desk. If the code works on copy paper and fails on the navy board, contrast was the cause. Reprint the light patch. Do not raise brightness in Photos and resend a JPEG.

Motion blur from a handheld poster at walking pace

Cause: a roll-up in an aisle is scanned while the guest is still moving. Low light and motion blur fail more often than the wrong app. A 2 cm symbol sized for a table tent is invisible from two metres.

Fix: size for the closest a scanner will actually stand. Chest-to-head height on a roll-up, not the footer. Matte laminate if gloss flares. Hold still is not a guest instruction you can rely on; millimetres are.

Confirm: walk the aisle with an iPhone videoing the poster, then freeze and scan. If it only works when you plant your feet at 30 cm, the symbol is too small for that placement. Reprint larger. A hosted dynamic code can keep the same ink while you fix the landing page; it cannot enlarge modules already on vinyl.

A 301 cache on an old hop

Cause: a previous generator or CDN issued HTTP 301 to an old URL. Some browsers and in-app webviews cache that forever, so later dashboard edits never reach that iPhone. SmartQRCode scan redirects are 302 so edits stay live. A 301 from elsewhere still poisons that device.

Pause is a separate state: a paused hosted code can send scanners to a paused page while the print looks perfect. User-archived codes keep scanning.

Fix: open the destination in Safari by typing it. If Safari has the old page and a fresh Android phone has the new one, you are looking at cache, not ink. Change the hosted target and confirm on a device that never scanned the 301. For a Wi-Fi join, there is no hop to cache; the payload is in the modules.

Confirm: test-scan on an iPhone that has never seen the old URL, in a private Safari session. If that device lands on the current target through a 302, the original iPhone needs its site data cleared or you need a new short URL.

Lock-screen scan variance is real and undocumented as a promise. Some iPhone versions offer a banner from the lock-screen camera; some do not. Do not write guest instructions that depend on a lock-screen chip. Instruct people to open Camera, point, and wait for the banner. If Screen Time already blocked Camera, that instruction fails first.

A dirty lens, a wet table tent, and a case that covers the camera cutout all mimic a generator bug. Wipe the lens. Dry the tent. Take the case off once. Then reprint. Confirm on a second iPhone that has none of those problems so you do not reprint for a smudge.

When another reader or a reprint is the next move

If Camera still fails after unrestricted Screen Time, a light patch, enough millimetres, and a hop that opens in Safari, try Google Lens on an Android handset as a cross-check. If both fail, the file is damaged: logo over a finder, grey from upscaling, or a quiet zone lost to trim.

Do not install a third QR app as the guest path. Current iPhone Camera is the path. Apps are a diagnostic.

A throwaway sign with a URL that will never change does not need a hosted account. Canva or another one-off static file is the right tool. A hotel Wi-Fi join is also static: reprint when the passphrase changes. If you needed counts or a destination swap after the cards shipped, the iPhone failure was never the camera; you picked the wrong encoding class.