Make an NFC Tag Open an App Instead of a Website

Quick answer

A plain URL record on an NFC tag opens a browser. That's it. To make a tap open your app instead, Android and iOS each need a different mechanism layered onto that URL. Android uses an Android Application Record (AAR) — a dedicated NDEF record tied to your app's package name. iOS uses an App Clip, invoked by an NFC-enabled App Clip Code. Already written custom NDEF records beyond URL and text? This is the next record type worth learning.

Step-by-step

Android: the Application Record

Android's NdefRecord.createApplicationRecord("com.your.package") embeds an Application Record in your tag's NDEF message. An AAR doesn't carry content the way a URL or text record does — it just names your app, so Android can launch it directly instead of asking the user to pick from a list.

Record order matters. An AAR shouldn't be the first record unless it's the only one on the tag. Android reads that first record to determine the MIME type or URI it uses for intent matching, and an AAR sitting there can break the match. Safe pattern: URL or text record first, AAR appended after.

If the named app isn't installed, Android doesn't just give up — it falls back to that package's Google Play Store listing. One more tap installs it.

iOS: App Clips

iOS has no direct equivalent to the Application Record. There's no "write a bare package identifier and let the OS sort it out." Apple's mechanism is URL-driven from the start: the App Clip.

In App Store Connect, you generate an App Clip Code as NFC-enabled or Scan-Only. NFC-enabled codes embed an actual tag, so a user taps instead of scanning; the visual code stays printed too, as a fallback. Tap, and the App Clip card surfaces on-screen — one more tap opens it, often skipping login entirely by linking straight to Apple Pay or an existing account.

If the App Clip isn't cached, it downloads on demand in the background. If the full app is already installed, iOS opens that instead — that's expected, not a bug. For background reading specifically, rather than an explicit App Clip tap, see why iPhone background NFC reading needs a Universal Link — related, but a distinct mechanism.

Writing one tag that works on both

iOS keys off the URL itself; Android can key off either the URL or the AAR. So the order that satisfies both platforms: URL record first, Android Application Record appended after. iOS reads the URL and ignores the AAR it doesn't recognize. Android checks for the AAR and launches your app directly, with the URL still sitting there as a fallback.

Common problems and fixes

• AAR ignored, wrong app opens — a record-order mistake. Move the AAR off the first slot unless it's the tag's only record.
• Tag opens Safari instead of the App Clip — the App Clip experience isn't registered for that exact URL, or the code wasn't generated as NFC-enabled.
• Full app opens instead of the App Clip — expected when the full app is already installed.
• Works on one platform, not the other — confirms these are separate mechanisms, not a shared standard. See iOS vs Android NFC: what each platform can really do for the broader comparison.
• Testing — use real devices per platform. Simulators don't reliably reproduce AAR or App Clip dispatch.

Doing this on NFCore specifically

NFCore's custom record editor supports multi-record NDEF messages. Add your URL record first, then a second record carrying the Android Application Record with your app's package name. Read the tag back afterward to confirm the order before you deploy it — reprinting because two records got swapped is a cheap mistake to avoid. Grab NFCore on the App Store or Google Play.

Frequently Asked Questions

Will one NFC tag open an app on both iPhone and Android?

Yes, if the record order is right: a URL record first, ideally one also registered as an App Clip experience, then an Android Application Record appended after. iOS keys off the URL; Android checks the AAR.

What happens if the app isn't installed?

Android's AAR fallback opens the app's Google Play Store listing automatically. On iOS, an NFC-enabled App Clip Code downloads and opens the App Clip on demand — no prior install needed.

Why does my Android Application Record sometimes get ignored?

Usually record order. The AAR is sitting first when it isn't the tag's only record, which breaks Android's MIME/URI intent matching. Move it after the URL or text record.

Can I use NFCore to write a tag that opens an app instead of a website?

Yes. Build a custom NDEF message with a URL record first and an Android Application Record second, using NFCore's custom record editor, then verify the order before handing the tag out.

Conclusion

One physical tag, two different platform mechanisms. That's app-launch-from-tag today. Android's Application Record and iOS's App Clip don't work alike, but they coexist fine on one tag if the record order is right: URL first, AAR after. Get that right the first time and you won't be reprinting tags later.