How the interaction works
When a device is described as NFC-compatible, it means the hardware includes a near-field communication chip and the operating system exposes that capability to at least some applications. That statement covers a wide range of actual behaviours, and the gap between "has an NFC chip" and "can reliably read your tags in the field" is where most deployment problems start.
NFC compatibility is not a single, uniform state. A device might support card-emulation for contactless payments but not tag reading. Another might read tags but restrict which apps can respond. A third might read tags only when the screen is on and unlocked. For anyone planning a physical deployment — whether in a museum, retail floor, event venue or heritage site — the practical question is not whether a phone has NFC, but what it can actually do with your specific tags under real visitor conditions.
Smartphones
The vast majority of smartphones sold in the UK since roughly 2015 include NFC hardware. On Android, tag reading is generally available to any application the user has installed, and the OS presents a tag-discovery prompt when a compatible tag is detected near the device. On iOS, Apple has progressively opened NFC access: from Apple Pay-only to NFC Tags reading in 2017, to background tag reading from iOS 13, and to broader developer access through Core NFC in subsequent releases. However, iOS still imposes constraints on what an app can do without foreground interaction, and background tag reading behaves differently depending on the iOS version and device model.
The practical implication is straightforward: if your deployment relies on a native app, you need to test the exact NFC interactions on both platforms at the minimum OS versions you intend to support. If you are using an app-free approach — where the phone's default NFC behaviour opens a URL — the experience differs between Android (which typically opens the browser directly) and iOS (which may show a system notification requiring an additional tap).
Tablets and Other Devices
Many tablets include NFC chips, but usage patterns differ from phones. A visitor is far less likely to carry a tablet through a museum or retail space and tap it against an exhibit label. Tablets with NFC are more relevant for staff operations — stock checking, exhibit maintenance logging or guided-tour devices handed out by the venue. Wearables such as smartwatches sometimes include NFC, but their tag-reading capability is typically limited to payment functions rather than general-purpose tag interaction.
Operating System Versions Matter
An older phone with an NFC chip running an outdated operating system may behave quite differently from the same hardware on a current OS. Background tag reading, URL handling and app-launch behaviour have all changed significantly in both Android and iOS over the past several years. When planning a deployment, specify the minimum OS versions you will support and test against them, rather than assuming that NFC hardware alone guarantees a consistent experience.
Implementation from marker to mobile content
App-Free URL Launches
The most common use case for NFC in public-facing venues is the app-free tap: a visitor touches their phone to a tag and a web page opens. This works reliably on most modern Android and iOS devices, but the user journey differs. On Android, the browser typically opens directly. On iOS, the system may display a notification that the user must tap to proceed. If your exhibit label or point-of-sale sign does not account for this extra step, visitors may assume the tag is not working.
For this use case, the tag must encode an NDEF record of the correct type — usually a URI record. Some tag formats or locked legacy tags may not trigger the expected OS behaviour on all devices. Always test with the exact tag type and encoding you plan to deploy, on both major platforms.
Native App Interactions
If your deployment uses a dedicated app, NFC compatibility extends beyond the hardware to the app's permissions and the OS version. On Android, the app must declare the NFC permission and ideally handle the tag-discovery intent. On iOS, the app must include the NFC Tag Reading capability in its entitlements and be actively running in the foreground for most tag-reading operations. Background tag reading on iOS can launch an app, but the system imposes rate limits and requires careful configuration to avoid inconsistent behaviour.
Staff and Operational Devices
For back-of-house or operational use — such as maintenance staff tapping tags to log checks, or retail colleagues scanning shelf tags for stock information — the device landscape is more controlled. You can specify exact phone models, OS versions and app configurations. In these scenarios, NFC compatibility is easier to guarantee because you are not relying on a visitor's personal device. The key consideration is ensuring that staff devices are kept on supported OS versions and that the NFC reading behaviour is not disrupted by device management policies or battery-optimisation settings.
Device Cases and Accessories
Phone cases, particularly those with metal elements or thick magnetic mounts, can attenuate the NFC signal. This is not a read-range question in the physical sense, but it is a practical compatibility issue: a device that reads a tag perfectly when uncased may fail when the user has a rugged or metallic case fitted. If your deployment environment involves industrial settings, construction sites or outdoor venues where rugged cases are common, include cased devices in your testing.
Testing, support and incident response
Assuming Universal Behaviour
The single most common mistake is treating "NFC-compatible" as a binary property. In practice, compatibility is a matrix of hardware, OS version, tag format, app configuration and user context. A tag that works on one visitor's phone may not work on another's, even if both devices have NFC chips, because of differences in OS version, case material, screen state or app installation.
Ignoring the Screen-On Requirement
On many devices, NFC tag reading requires the screen to be on and, in some cases, the device to be unlocked. A visitor who taps a tag with their phone in their pocket or with the screen off will see no response and may conclude the system is broken. Signage and instructions should set the expectation clearly — "wake your phone and tap" rather than simply "tap here" — and your pilot testing should include screen-off and locked-device scenarios to understand exactly what happens on each platform.
Overlooking OS-Level Restrictions
Both Android and iOS have introduced changes to NFC behaviour over time. Android has varied how it handles multiple apps registered for the same intent. iOS has adjusted background tag-reading frequency and notification behaviour. If you test on current devices at the time of planning but deploy six months later, new OS updates may have altered the user experience. Build a verification step into your deployment timeline that retests key interactions after any major OS release.
Not Testing with Real Visitor Devices
Testing with a small set of known-good devices — typically recent-model phones on current OS versions — gives a false sense of reliability. Real visitors arrive with a long tail of older devices, budget handsets, modified OS configurations and non-standard cases. During any pilot phase, deliberately include a range of device ages, price points and case types in your test group. Record which devices succeed, which fail and why, then use that data to set realistic expectations in your visitor communications.
Key Checks Before Deployment
- Confirm the exact NDEF record type and encoding on your tags matches the behaviour you expect on both Android and iOS.
- Test with the minimum OS versions you intend to support, not just the latest releases.
- Include cased devices, screen-off devices and locked devices in your test matrix.
- Verify that app-free URL launches produce a clear, actionable result on iOS — accounting for the notification tap — rather than a silent failure.
- If using a native app, confirm NFC entitlements, permissions and foreground requirements on both platforms.
- Check whether any device management or battery-optimisation settings on staff devices interfere with NFC reading.
- Plan a retest cycle around known OS release schedules for both Android and iOS.
NFC compatibility, understood properly, is a starting point for testing rather than a guarantee of behaviour. The hardware is now widespread, but the software and contextual layers above it still demand careful, device-specific verification before any public deployment.
