# Passport NFC Chip Reader UI in SwiftUI

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-07. 6 min read.
> Source: https://vp0.com/blogs/passport-nfc-chip-reader-ui-swiftui

The chip is access-controlled by design. You cannot tap and read; you read the printed page first, which is also what stops skimming.

**TL;DR.** A passport NFC reader reads an official, signed identity document (ICAO 9303 e-passport chip), so it is a high-trust build. The chip is access-controlled: you must OCR the printed Machine Readable Zone first to derive a BAC/PACE access key proving physical possession, then use Core NFC's ISO 7816 APDU support to handshake and read the data groups, and verify the issuer's cryptographic signature rather than trusting raw output. The UI is mostly coaching, where to place the phone, a hold-still progress state over the few-second read, specific failure recovery, because the document is irreplaceable and the user is anxious. Consent before the scan, minimize and protect the data. A free VP0 design supplies the MRZ-capture and read screens.

## 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](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/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](https://developer.apple.com/documentation/corenfc/nfciso7816tag) 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](/blogs/swiftui-nfc-reader-bottom-sheet-template/) 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](/blogs/franceconnect-mobile-login-flow-ui-react-native/), 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](https://vp0.com) 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.

## 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 passport 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 like 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 since 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.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*