How do you read and write NFC from your own code?

Four ways in, four sets of rules

On Android, the NFC framework hands a discovered tag to an activity, which can read and write NDEF, send raw commands to the tag, or answer a reader through host card emulation.

On iPhone, Core NFC lets an app read inside a session that the system displays and ends, the model this site describes on the scan sheet page.

In a browser, Web NFC reads and writes NDEF from a web page. Chrome documents it as available on Android from Chrome 89, and limits it to NDEF on purpose: no raw commands, no card emulation.

On a computer, a USB reader is reached through PC/SC, the specification computers use to talk to smart card readers, and the program talks to the tag through the reader rather than through a phone.

They differ in what they can send to a tag, and they differ even more in when they are allowed to listen. That second difference is the one a port from one platform to another gets wrong.

What code has to declare

None of them reaches the radio unannounced. An Android app asks for android.permission.NFC, which the permission reference classes as normal, so it is granted at install without a prompt.

From Android 17, an app that targets a newer SDK must also protect each activity that receives tags with android.permission.DISPATCH_NFC_MESSAGE, according to the NFC basics guide, so that only the NFC service can start it.

An iPhone app declares the Tag Reading capability and a usage description before Core NFC opens a session, and a tag session that reads ISO 7816 tags also lists the application identifiers it will select. The declarations page covers all three.

A web page needs a secure origin, a top level frame and a gesture from the visitor, such as a tap on a button, before Chrome asks for the nfc permission.

What the field does to code

A tag is present for as long as a hand holds it still, and the code runs inside that window. The TagTechnology reference marks every exchange as blocking and forbids it on the main thread, and a tag that leaves mid exchange raises TagLostException.

Tests at a desk hide this. The phone lies flat, the tag does not move, and the window never closes. The same code in a visitor's hand meets a window that closes halfway, and code that has never met that case treats it as a crash.

The tag is also not what it was a second ago. Android caches what it read at discovery and never updates those values, so a program that writes and then trusts the cached copy reads back its own assumption.

Checking what the code wrote

Read the result back with a tool that is not the code under test. A bug that writes the wrong record type can read it back as the right one, because the same bug decodes it.

NFC Tools, published by the same company as this site, shows the records a tag holds and the technologies it reports, which settles most disagreements between a program and its author.

Then read the tag on the other platform. A message an Android parser accepts can still do nothing on an iPhone, a platform decision covered on the iOS records page.