Platform:
CPU card configured as an NFC Forum Type 4 Tag with:
NDEF Tag Application AID: D2 76 00 00 85 01 01
CC File ID: E1 03
NDEF File ID: E1 04
CC and NDEF file content is identical on two test cards and validated against the Type 4 Tag Operation v2.0 specification.
Observed Behavior:
Android devices read the NDEF message without issue.
iOS (iPhone) stops immediately after the SELECT AID command when the card returns a complete FCI that includes the NDEF File Control TLV (tag 04).
A second card that returns only 90 00 (no FCI data) to the same SELECT AID command works perfectly on iOS. In that case, iOS correctly falls back to the default CC File ID (E1 03), reads the CC file, locates the NDEF file, and retrieves the NDEF message.
Is there a specific FCI make iOS recognize Type 4 Tag?
Correct me if I’m wrong but I don’t think the ndef aid should return anything other than status words of 90 00. Is there a part of the NFC type 4 spec that counters this you could post?
I find Apple and iOS to be extremely pedantic when following standards, whereas Android will pretty much wing it just to make things work.
iOS parses an FCI payload strictly, if there’s a malformed structure or unexpected data bytes inside the FCI the engine crashes or aborts the reading session instead of skipping it. Returning the raw 90 00 (no FCI payload) is working because iOS is falling back to the default CC file ID, E1 03.
I quick check of my notes tells me that FCI is optional for ndef application selection and it is actually based on the P2 value being 00 on the selection command which requests FCI. So, either omit FCI and simply return 90 00 which is fully spec compliant, or go through the challenge of determining exactly what FCI iOS expects.
The Type 4 Tag Operation Specification does not define FCI. Whether to return FCI is optional。Really don’t know the FCI expected by iOS。I have tried many combinations, but all failed。
