An RFID scanner app on a phone reads NFC tags, not UHF tags.
People asking for an RFID scanner app usually mean one of two things, and a stock phone can only do one of them. Short range NFC tags, the sort stuck on a laptop lid or a fire extinguisher, a phone reads directly. Long range UHF RFID tags, the sort a gate reads as a pallet rolls past, a phone cannot read at all. That split decides the hardware budget and half the screens, so settle it before anything else. It is a different starting point from barcode scanner to Excel apps, where the camera already does the reading.
This page covers which tags a phone can actually read, where UHF RFID begins and the phone stops, what a scan has to record to be worth keeping, and why counting is a different job from scanning.
See which tags a phone can readThe short version
One radio decides the project, and it is fitted or it is not.
Every hard decision here follows from one fact: the phone has an NFC reader and does not have a UHF RFID reader. NFC is centimetres. UHF is metres, in a band the handset has no antenna for.
If your tags are NFC, the app is the whole product and the tap is nearly free. If your tags are UHF, the phone is a screen for a reader you buy separately, and the app is a Bluetooth client with a scanning workflow on top. Two different projects wearing the same name.
Where UHF RFID starts and the phone stops
The picture most people have of RFID, a reader pulling a hundred tags out of the air at a doorway, is UHF. GS1 describes its EPC Gen2 air interface protocol, first published in 2004, as defining the physical and logical requirements for an RFID system of interrogators and passive tags operating in the 860 MHz to 930 MHz UHF range. A phone has no radio in that band, so there is nothing for an app to talk to.
That is worth stating plainly, because it usually gets sold as a software problem. It is not a permission, an entitlement or a package somebody forgot to install. The antenna is absent. No app on any phone reads a UHF RFID label, at any distance.
So an RFID tag reader app for UHF has a different shape. You buy the reader: a sled that clips to the phone, a Bluetooth handheld, or a fixed portal over a doorway. The app pairs with it, takes a stream of tag reads, removes the duplicates and turns the rest into a count or a movement. That is a real and useful app. It is also a Bluetooth client, and Bluetooth is another thing you cannot exercise on a simulator.
If the tags have not been bought yet, price a printed label against a UHF one first. An inventory barcode scanning app needs no reader at all, and it gets a lot of operations to the same place for the cost of a roll of labels.
The tap is easy, the record is the app
Reading a tag is a few lines of code. Deciding what the read means is the whole build. A scan that yields a tag identifier and nothing else leaves you with a list of numbers and no way to answer a question about them.
A useful scan writes a row: the tag identifier, the asset it is bound to, who scanned, when, where if you have it, and the intent. Check out, check in, count, move, inspect. Intent matters more than people expect, because the same tap at the store room door means opposite things, and an app that asks afterwards will get the wrong answer.
Keep the binding between tag and asset as its own record rather than a column. Tags fall off, get replaced, and occasionally get stuck on the wrong thing. An app that treats the tag identifier as the asset identity cannot correct that without losing history. The same discipline is what makes an equipment inspection app answerable a year later: the event is the record, not a flag on the item.
Counting is a different job from scanning
Scanning answers where one thing is. Counting answers what is in this room, and that is the job most people actually want from an RFID inventory app. A count needs a session with a start, an expected set, the tags seen, and then the part that earns its keep: what was expected and not found, and what was found and not expected.
Duplicates are the other half. One tag gets read six times in a sweep and the count has to treat that as one item, while a genuine second tag stays separate. Resolve it in the session as the reads arrive, because the person wants to watch the number move while they are still in the room.
None of this survives a bad connection, and a stock room is usually the worst signal in the building. The count has to live on the device and reconcile afterwards, which is a design problem of its own. Work out how you want scanning in a warehouse with no signal to behave before you decide where the count is stored.
What each way of scanning actually gives you
| Approach | Reads UHF RFID tags | Works on a stock phone | Extra hardware | Reads inside a box |
|---|---|---|---|---|
| Phone camera and barcodes | No | Yes | none | No |
| Phone NFC, one tag at a time | No | Yes | none | thin packaging only |
| Bluetooth UHF sled on a phone | Yes | Yes | one reader per user | Yes |
| Handheld UHF gun | Yes | No | one device per user | Yes |
| Fixed UHF portal at a doorway | Yes | No | one per doorway | Yes |
Building one around the tags you already have
Asset tracking platforms are priced per asset or per user per month and are built around their own tag scheme and their own idea of a check out. That works until the tags are already on the equipment, or the workflow has a step the platform does not model, or the count has to be signed off by somebody without a seat.
Newly is an AI app builder. You describe the app, including which tag is actually in your hand, and it writes a real React Native and Expo project you own and builds it in the cloud. Plans start at $25 a month, there is no free plan, and iOS builds ship through TestFlight and App Store Connect using your own Apple Developer account.
On NFC specifically, here is what we could confirm. The NFC reader library is a native package, so adding it triggers a fresh native build rather than a JavaScript update, and Newly turns on the iOS NFC capability for your bundle ID from the app config when you publish. What no builder can hand you is a tap on a cloud simulator, because a simulator has no NFC radio. The first genuine scan happens on a real handset, which on iOS means TestFlight and a paid Apple Developer Program membership. Plan the tag testing around that rather than assuming the preview will show it.
Questions people ask about RFID scanner apps
It depends which RFID. A phone reads NFC tags, which are short range and usually stuck on individual items. It does not read UHF RFID tags, the long range kind used on pallets and cartons, because it has no radio in that band. No app or setting changes that.
Start with the tag in your hand
Work out whether your tags are NFC or UHF before you write a line, then describe the scan, the record it writes and who needs to see it.
Start building