Passport NFC Chip Reader UI in SwiftUI

What is actually being read, and what is the iOS reality?

The chip inside an e-passport (and many national ID cards), which holds the holder’s data signed by the issuing country. A biometric passport contains an NFC chip following the ICAO 9303 standard: name, date of birth, document number, nationality, the photo (a compressed facial image of roughly 15,000 to 20,000 bytes in DG2), and a cryptographic signature proving the data is genuine and unaltered. Reading it on iPhone is possible, Apple exposes the right NFC mode, but it is one of the more demanding NFC tasks because the chip is access-controlled, not an open tag.

The honest framing first: this reads an official identity document, so it is a high-trust, high-responsibility build (KYC onboarding, border-style verification, age assurance), and the design has to treat the data accordingly. You are not scanning a loyalty card; you are handling government-issued identity, which raises the bar on security, consent, and honest scope at every step.

Why can’t you just tap and read it?

Because the chip requires a key derived from the printed document to unlock it, by design. The passport’s data page prints a Machine Readable Zone (MRZ), and the chip will not talk until the app proves it has physical access to the document by presenting a key computed from MRZ fields (document number, date of birth, date of expiry), the Basic Access Control / PACE mechanism. So the real flow is two stages:

Stage	What happens	Why
Read the MRZ	OCR the printed lines, or manual entry	Derives the access key; proves physical possession
Establish access	BAC/PACE handshake with the chip	The chip refuses to open without it
Read the data groups	NFC read of DG1 (text), DG2 (photo), etc.	The actual chip data, now unlocked
Verify the signature	Check the issuer’s cryptographic signature	Proves the data is genuine, not forged

On iOS this uses Core NFC’s ISO 7816 tag support to send the APDU commands the protocol requires, which is lower-level than a typical tag read. The MRZ-first requirement is the part that surprises builders: you cannot read the chip from the NFC alone, you need the printed document first, which is also the security property that stops remote skimming.

What does the scanning UI owe a nervous user?

Reassurance and clear staging, because holding a passport to a phone is unfamiliar and the read is finicky. The chip is small and the antenna coupling is fussy, so the UI must coach: where to place the phone on the document (it varies by passport), a clear “hold still, reading…” state with progress (the read takes a few seconds, not instant), and honest, specific failure recovery (move the phone, the chip is usually near the photo page) rather than a generic error. A passport read that fails silently or vaguely sends the user in circles, so the read-state coaching is most of the UX.

The MRZ capture stage gets the same care: OCR-ing the two printed lines with a guided camera frame, with manual entry as a real fallback because glare and worn documents defeat OCR often. The same scan-resilience-and-coaching discipline as any NFC tap-to-read flow applies, raised because the document is irreplaceable and the user is anxious about it.

What is the security and honesty bar?

High, and stating it plainly is part of the build. Three rules. Consent and purpose: reading someone’s passport is a serious data event, so the app explains what it reads and why before the scan, not after. Verify, do not just read: the value of the chip is the issuer’s signature, so a serious app checks it (the data is genuine and unaltered) rather than trusting raw chip output, since an unverified read can be spoofed. And minimize and protect: identity data is the most sensitive there is, so read only what the use case needs, handle it server-side under proper security where the verification happens, and never log or cache it carelessly, the same data-minimization posture as the FranceConnect identity flow, at the document level.

The screens, the MRZ capture, the tap-and-hold read with coaching, the verified-result summary, come as a free VP0 design, so an agent builds the Core NFC ISO 7816 flow onto a UI that already stages MRZ-then-chip and shows verified identity honestly rather than dumping raw chip data.

Key takeaways: a passport NFC reader

• It reads an official, signed identity document: a high-trust build (KYC, verification), handled accordingly at every step.
• MRZ first, then the chip: the printed document derives the access key (BAC/PACE); you cannot read the chip from NFC alone.
• It uses Core NFC’s ISO 7816 APDU level, lower-level than a typical tag, and the read takes seconds with fussy antenna coupling.
• The UI is coaching: where to place the phone, a hold-still progress state, and specific failure recovery for an anxious user.
• Verify the signature and minimize the data: check the issuer’s signature, read only what is needed, protect it; consent before the scan.

Frequently asked questions

How do I build a passport NFC chip reader in SwiftUI? Read the printed MRZ first (OCR or manual entry) to derive the BAC/PACE access key, then use Core NFC’s ISO 7816 tag support to handshake with the chip and read its data groups, and verify the issuer’s cryptographic signature. Coach the user through placement and a hold-still read state. A free VP0 design supplies the MRZ-capture and read screens.

Why do I need to scan the passport’s printed page before the chip? Because the chip is access-controlled: it will not open until the app presents a key derived from the Machine Readable Zone (document number, date of birth, expiry), proving physical possession of the document. That MRZ-first requirement is also the security property that prevents remote skimming of the chip.

Can an iPhone read e-passport chips? Yes: iOS exposes Core NFC’s ISO 7816 support to send the APDU commands the ICAO 9303 protocol requires, so an app can perform the BAC/PACE handshake and read the data groups. It is more demanding than a typical NFC tag read because the chip is access-controlled and the read takes a few seconds.

How should the scanning UI handle a finicky read? With coaching, not generic errors: tell the user where to place the phone on the document (it varies by passport), show a clear hold-still progress state since the read takes seconds, and give specific recovery (“move the phone, the chip is usually near the photo page”). The antenna coupling is fussy, so read-state coaching is most of the UX.

Is reading a passport chip a security concern? Very much so: it handles official identity data, so explain consent and purpose before the scan, verify the issuer’s signature rather than trusting raw chip output (unverified reads can be spoofed), read only what the use case needs, and protect the data server-side. Identity data demands the strictest minimization and security posture.