Why iPhone Background NFC Tag Reading Needs a Universal Link
If an NFC tag opens Safari instead of an app on iPhone, the tag isn't the problem — the URL isn't a working universal link. Here's what background NFC reading actually checks, and the setup mistakes that break it silently.
What It Is
iPhone's background NFC tag reading only hands a tap off to an app when the tag's NDEF record contains a valid Apple Universal Link — not a plain URL, and not a custom scheme like myapp://. If the link doesn't resolve to a properly configured universal link, iOS treats it like any other web address and opens it in Safari.
That's why background NFC reading confuses people. A tag can look completely correct — you tap it, the phone buzzes, a screen opens — and still fail, because "a screen opened" isn't the same as "the right app opened." Here's what iOS actually checks before routing a tap, and the setup mistakes that cause a tag to quietly fall back to the browser.
How It Actually Works
When you tap a tag with the screen locked or the app closed, iOS reads the NDEF message and looks at the first record only — a universal link in a second or third record is ignored. That record has to be a URI type pointing to a domain the app has explicitly claimed. Beyond https:// links, the only other schemes iOS honors in the background are mailto:, sms:, tel:, FaceTime, Apple Maps, and HomeKit's X-HM://. Custom app schemes never trigger background routing, even though they work in a foreground Core NFC session. (See our pieces on NDEF URI records and NFC Forum tag types for how tags encode this.)
Claiming a domain requires the Associated Domains entitlement in Xcode, plus a signed apple-app-site-association file hosted on that domain over HTTPS. Without both, iOS opens the link like a plain bookmark.
It also needs an iPhone XS or newer, unlocked at least once since restart. And it pauses while a foreground NFC session or Apple Pay transaction is active, the camera is in use, or Airplane Mode is on. None of this happens silently — a system notification appears first, and the user has to tap it before the app opens.
Where You'll See It
This matters most for tap-to-launch cases: a Shortcuts automation from a desk tag, a smart-home scene, a business-card tag that should open a contact-save screen instead of a webpage, or an event wristband meant to land attendees in a check-in app. A plain https:// tag works everywhere but can't hand off to an app — a universal link only pays off once the domain-to-app mapping is genuinely in place.
This is also where things get confusing. Developers have reported cases where everything on paper was correct — a signed association file, the applinks: entry, a passing validator — and the tag still opened Safari. Usual culprits: a signing-certificate mismatch, a stale validation cache on the device, a Team ID mismatch, or the file not served as application/json. None of it throws a visible error; the tag just keeps defaulting to the browser.
Tips, Gotchas, and a Quick How-To With NFCore
Before assuming a tag is broken, check in order: is the URL record first on the tag, is Associated Domains enabled for the app, and is the hosted association file HTTPS, signed correctly, and served as application/json.
To verify what's actually written to a tag you own, NFCore's Tag Inspector reads back the raw NDEF payload so you can see which record is first and what the URL really is. To encode the link yourself, you can write a tag's NDEF record yourself with NFCore's writer, setting the URI record directly.
Worth being upfront: NFCore can confirm what's on the tag, but it can't fix a broken universal-link configuration — that's an app-developer-side setup issue, not something a reader/writer app changes.
Frequently Asked Questions
Why does my iPhone open Safari instead of my app when I tap an NFC tag?
The URL on the tag isn't recognized as a working universal link. When iOS can't map the domain to an installed app, it opens the URL like any ordinary web address — with no error, so this looks identical to a working tag from the outside.
Can I use a custom URL scheme like myapp:// on an NFC tag for background reading?
No. Background tag reading only routes through Apple Universal Links, plus a short list of system schemes like mailto:, tel:, and Apple Maps links. Custom app schemes are silently ignored in the background, even though they work in a foreground Core NFC session.
Which iPhones support background NFC tag reading?
iPhone XS and newer, unlocked at least once since the last restart. Reading also pauses while a foreground NFC session, Apple Pay transaction, or the camera is active, or while Airplane Mode is on.
Why does a tag still open Safari even though my universal link setup looks correct?
Universal links depend on a signed configuration file hosted on your domain, and that validation can fail quietly: a certificate mismatch, a stale device-side cache, a Team ID mismatch, or the wrong content type on the file. There's no error message for any of it — the tag just keeps falling back to the browser.
Conclusion
Whether a tapped NFC tag opens an app or just a browser tab comes down to one thing: a correctly configured universal link, not the tag itself. Get the record order, the Associated Domains entitlement, and the hosted association file right, and the handoff is instant. Get any one wrong, and the tag will still "work" — it just won't do what you built it to do.