Thank you for confirming ISO 14443-B support. Given that, I looked deeper at the tag characteristics and the NDEF data record.
I used NXP TagInfo to gather more detail about the data written on the tag and its characteristics. TagInfo returns the following information when reading the RF430 tag with the Android system (3 screenshots):



Reading RF430 with the iPhone only gives:

I wrote the same "Hello, world!" message into an NXP NTAG213 and read it back. The results are (5 screenshots):





The NXP NTAG213 returns more information than the RF430, but the NDEF data is the same.
I also asked Gemini to analyze the RF430 tag contents and it said the data was a valid NDEF record and container:
Let's break down the provided data and analyze its validity for an NTAG 4 tag (which is an ISO 14443 Type 4 tag).
- Tag Selection (0xD2, 0x76, 0x00, 0x00, 0x85, 0x01, 0x01)
• This sequence looks like a typical SELECT command for an NXP tag. The specific AID (Application Identifier) used (D2760000850101) is the standard AID for NXP's NTAG and MIFARE Ultralight C tags.
• This part is valid.
- Capability Container (CC)
• 0xE1, 0x03: Correct magic number for CC.
• 0x00, 0x0F: CCLEN (Capability Container Length). This is 15 bytes, which is correct.
• 0x20: CC version 2.0, also correct.
• 0x00, 0x3B: MLe (Maximum R-APDU data size). 59 bytes, valid.
• 0x00, 0x34: MLc (Maximum C-APDU data size). 52 bytes, valid.
• 0x04, 0x06: File Control TLV. Tag=0x04 (NDEF file), Length=0x06. Correct.
• 0xE1, 0x04: File Identifier for NDEF file. Correct.
• 0x0B, 0xDF: Max NDEF size. 3039 bytes. This appears to be correct for a NTAG 424 DNA.
• 0x00: NDEF file read access condition. Read access without security. Correct.
• 0x00: NDEF file write access condition. Write access without security. Correct.
• Validity: The CC is valid.
- NDEF File Identifier
• 0xE1, 0x04: File identifier for the NDEF file. This matches the one specified in the CC, which is correct.
- NDEF Data
• 0x00, 0x14: NLEN (NDEF Message Length). 20 bytes.
• 0xD1, 0x01, 0x10, 0x54, 0x02, 0x65, 0x6E: NDEF Record Header. This is a valid Text record header.
o D1: MB=1, ME=0, CF=0, SR=1, IL=0, TNF=1 (Well-known type)
o 01: Type Length =1
o 10: Payload Length = 16
o 54: Type = 'T' (Text)
o 02: Status byte. Indicates UTF-8 and language code length.
o 65, 6E: Language code "en".
• 0x48, 0x65, 0x6C, 0x6C, 0x6f, 0x2c, 0x20, 0x77, 0x6f, 0x72, 0x6C, 0x64, 0x21: Payload "Hello, world!". 13 bytes.
• Validity Issues:
o The NLEN value (20 bytes) does not match the actual NDEF message length (13 bytes payload + 7 bytes header = 20 bytes). Therefore, the NLEN is correct.
o The payload size of 13 bytes plus the header size of 7 bytes equals 20 bytes. That matches the NLEN.
o The NDEF data is valid.
Overall Validity
The entire data sequence appears to be valid for an NTAG 4 tag. The CC is correctly formatted, and the NDEF message is well-formed.
In summary:
The provided data is valid and can be written to an NTAG 4 tag. The tag selection, capability container, and NDEF message are all correctly formatted.
Do you see anything in the comparison between the RF430 and NTAG213 screenshot data that would cause the iPhone to error out and reject it?