Web page or native app: which one for an NFC project?
It depends first on the phones. A page using Web NFC reaches Chrome on Android and nothing else, while a native app reaches iPhones, raw commands and card emulation. Many projects need neither: when the tag only has to open a page, a link on the tag works on both platforms without any NFC code.
Reading the tag or opening a page
Most public projects never read a tag in code. A link written on the tag is opened by the phone itself, on Android and on iPhone, and the page at the other end needs no NFC API at all. The one tag for every phone page gives the recipe.
Code comes in when something has to happen between the tap and the page: reading several tags in a row, writing tags, checking an identifier, or talking to the chip. That is where the choice between a page and an app starts.
What each can reach
| Question | Web page | Native app |
|---|---|---|
| Phones reached | Chrome on Android | Android and iPhone |
| Content | NDEF only | NDEF and raw commands |
| Card emulation | No | On Android, through host card emulation |
| Started by a tag when closed | No | On Android through the manifest, on iPhone through a link the app claims |
| Distribution | A web address | A store listing |
The table is lopsided on purpose. The Chrome article on Web NFC explains that the API was limited to NDEF because the security properties of reading and writing NDEF data are easier to quantify.
When the page wins
For staff tools on phones the project controls, a page is hard to beat: no store review, no installation, and an update is a deployment of the site. The article's own examples are of that kind, inventory management and badge checks at a conference.
Its conditions fit that setting. Chrome on Android can be required of a fleet, the permission is granted once per site, and the page stays open on screen while people work.
When the app wins
As soon as iPhones must read or write tags, the page is out. The Chrome platform status entry lists no iOS support, and WebKit's published position opposes the API. An iPhone reads tags through Core NFC, inside an app.
The app also wins below NDEF, for passwords, counters, signatures and card emulation, and wherever a tag should start it without the user opening anything first, which only an installed app can arrange.
A cross platform framework can share the code between the two apps, within the limits described on the frameworks page.
Frequently asked questions
Can one web page cover Android and iPhone?
For reading or writing tags, no: Web NFC runs in Chrome on Android only. For opening a page from a tag, yes: write its address on the tag and both platforms open it.
Is Web NFC a web standard?
It is specified in a W3C Community Group, which Chrome's platform status entry describes as incubation, and only Chrome ships it. WebKit's published position opposes it and Mozilla's is negative.
Which one is cheaper to build?
The page, for staff on Android phones running Chrome. The app, as soon as iPhones or anything below NDEF are involved, since the page cannot reach them at any cost.
Can a tag open a page that then reads other tags?
On Android with Chrome, yes: the tag opens the page, and the page starts scanning after a tap on a button. The first tag is handled by the phone itself, not by the page.