We did extensive research on the subject, there is no mystery. iOS will only read MIFARE tags with NDEF formatted data.
If you write NDEF data to a formatted MIFARE card, it will be 'compatible' with iOS.
Otherwise, only the UID can be detected.
The real mystery is why Apple refuses to open the low-level read commands. (To read NDEF, or determine that the data is _not_ NDEF, you need to read the card.)
It's not a mystery - it's anti-competitive behavior where they only want to give access to low-level NFC access (required to enable things like door locks, car keys, payment/loyalty card systems, transport, etc) to "partners" who sign an NDA and agree to a rev-share.
For all the things wrong with/bad about Apple's iron grip on low-level interfaces, in this case that's not the only reason:
MIFARE Classic uses a mandatory, proprietary (presumably still patented) encryption algorithm even for "world-readable" cards, on top of the ISO 14443-3 standard. I'm not even sure whether Apple could legally offer that capability without licensing it from NXP.
On Android, only devices with an NXP chip support these tags for the same reason.
You could argue that Apple could just provide even lower layer access to the contactless interface to allow apps to implement it in software, but I'm not sure if that's feasible (due to timing constraints).
(Note that the article doesn't specify which MIFARE tags it is about. If it's MIFARE Classic, something must have changed, and maybe Apple has licensed the required NXP patents? DESfire should work with iOS without jumping through any hoops, since that implementation is ISO 14443 compliant all the way up to -4.)
Seconded. There’s almost certainly NXP IP used in nearly all NFC implementations which makes them subject to their terms.
Those terms are in turn set by the partners that asked for these technologies to be developed in the first place. And so any development gets slowed to a crawl in this space.
That's for card emulation. This article is about using iOS devices as readers.
ISO 14443 card reader functionality has been made available some iOS versions before, but it's still restricted (e.g. you can't select any "payment" ISO 7816 applications, you have to predefine the list of AIDs you want to be able to select, and you don't have lower layer access to ISO 14443).
I'm not aware of any announcements to further open up "reader" mode.
Big companies that can afford to pay the certification fees maybe can; I definitely can’t. The entitlement is not available to regular app developers, unfortunately.
In the EU, maybe. And even then you will most likely need to beg for an "entitlement" to use it which may have requirements around being a registered business, etc so hobby apps are still excluded.
There's two versions of access to "card emulation" mode:
- The EEA-only HCE (which lets you emulate the card in your app in software, for a limited list of use cases, which makes it a non-starter for fully offline systems unfortunately, as there's no protection against exfiltrating any keys from the app), and
- The some-non-EEA-countries-only "full smartcard access" solution, which requires you to pay Apple and do a ton of (presumably also very expensive) certification.
So for different reasons, neither is something in scope for hobbyists at the moment, unfortunately.
Back in 2015 I was tech lead for a modern (web based) SaaS library management system and getting it to work with RFID tags with a wrapper application was all sorts of fun and games.
We got RFID library tags working on Android, but with iOS locking down NFC access it turned out to be impossible and we had to get libraries to buy bluetooth connected RFID scanners.
Otherwise, only the UID can be detected. The real mystery is why Apple refuses to open the low-level read commands. (To read NDEF, or determine that the data is _not_ NDEF, you need to read the card.)