The problem could be that they require a different data format then the NFC Data Exchange Format (NDEF) as that is the only format that CoreNFC supports.

iOS apps can access NFC capablities on devices with that have appropriate hardware support, but from what I understand the CoreNFC API has some limitations.

For example, it doesn't provide a way to read an RFID'c unique ID without using a private API that would disqualify an app from being published on the app store. There's some information about this at [1] and [2]. CoreAPI can read NDEF tags, but they don't expose the UID.

Perhaps the Home Office's app needs the UID of the passport's embedded RFID? I don't know why they might want this, or why Apple restricts the ability to read it. Privacy concerns?

[1] https://www.taptrack.com/article/blog/core-nfc-2/

[2] https://stackoverflow.com/questions/51822226/corenfc-not-rea...

You need to do a proper cryptographic handshake with the passport, something impossible with the current SDK. You need to be able to send raw “APDUs” (commands) to the smart card/passport.

Is this available via a private API in CoreNFC? Is that what they're asking for?

Edit:

> and by the way, passports don’t have one

Thanks - I didn't know that. Now reading about Pseudo-Unique IDs.

Seems like there are some classes in the SDK that hint at that but so far they don’t work (presumably they require an entitlement that only Apple can provide).

I am sure you can see the advantages?