What should an app do when NFC is off or missing?
Tell the states apart before writing any message. On Android: no controller at all, a controller the user switched off, and, from Android 16, tags refused for your app. On iPhone: available or not. Then say which one it is, and let the rest of the app work.
Three states on Android
They need different answers, and the controller limits page reads them at runtime. getDefaultAdapter() returns null when the phone has no NFC controller: the feature does not exist and never will on that device. isEnabled() returns false when the user has switched NFC off, which is a setting away from being fixed. And from Android 16 a user can refuse tag intents for one app, which isTagIntentAllowed() reports while the adapter says it is on.
The third is the one that produces the best bug reports, because everything looks right: NFC is enabled, the app is installed, the manifest is correct, and no tag ever arrives.
Two on iPhone
Core NFC answers before a session exists: readingAvailable says whether the device can read. Beyond that, the errors carry the rest, readerErrorRadioDisabled for a radio that is off and readerErrorUnsupportedFeature for something the session cannot do.
There is no equivalent of the Android settings screen to send the user to, which changes the wording rather than the logic: an iPhone that cannot read is a device fact, and the app's job is to say so once and move on. Which iPhones read at all is the models page.
What to say for each
No hardware: hide the feature rather than explain it. A button that cannot work on that phone is a support ticket waiting, and its absence needs no sentence.
Switched off: offer the setting. Android exposes the NFC settings screen as an intent, and sending the user there beats describing where it lives, since the path differs by manufacturer, which the enabling page shows.
Refused for the app: say that, because nothing else in the interface will. The user chose it, possibly by accident, and only your message connects the silence to the setting.
Never block the rest
A tap is one input among several. An app that refuses to start without NFC has turned a convenience into a requirement, and the user who cannot use it is the one who needed the alternative.
Keep the manual path: a code to type, a search, a scan, whatever the tag was shortening. And decide separately whether the app should install at all on a phone without the radio, which is a store question rather than a runtime one: the store page takes it.
Frequently asked questions
How do I know the phone has no NFC at all?
getDefaultAdapter returns null on Android, and readingAvailable is false on iOS. Both are device facts, not settings.
Can I switch NFC on from my app?
No. You can send the user to the NFC settings screen on Android; the switch belongs to the user.
Why does nothing arrive although NFC is on?
From Android 16 the user can refuse tag intents for one app. isTagIntentAllowed reports it, and nothing else in the interface will.
Should the app refuse to run without NFC?
No. Keep the manual path and let the rest of the app work. Whether it installs at all is a separate, store level decision.