Can a cross platform framework reach every NFC feature?
No more than its NFC plugin wraps. Frameworks such as Flutter and React Native reach platform APIs through native code, so a plugin exposes what the Android and iOS APIs offer, and only what its author chose to wrap. The declarations stay in the native projects, and an app rendered in a WebView gets no Web NFC.
A plugin is native code
Cross platform frameworks reach platform APIs through native code. Flutter documents platform channels for calling a platform's APIs from Kotlin or Java on Android and Swift or Objective-C on iOS, and React Native documents native modules for platform APIs that neither it nor an existing library provides.
An NFC plugin for either is code of that kind. On Android it calls the technology classes and the dispatch covered in this section, and on iOS it calls Core NFC. It can expose what those APIs offer, and only the part its author wrapped.
The declarations stay native
A framework does not remove what each platform requires. The NFC permission, the intent filters and, from Android 17, the dispatch permission on the receiving activity all live in the Android manifest, as the manifest page describes.
On iOS, the reading capability and its usage description belong to the iOS project the framework builds, exactly as they would for an app written in Swift.
Where the two platforms differ
A single API over two platforms has to decide what to do with what only one of them offers. Android can start an app from a tag through its manifest, choose between reader mode and foreground dispatch, and emulate a card through host card emulation; iOS reads inside a session the system displays.
A plugin either exposes the common part only, or adds calls specific to one platform that the shared code must branch on. The first hides the Android features, and the second brings back the two code paths the framework was meant to remove.
Apps rendered in a WebView
Frameworks that render the app in a web view are a separate case. The Chrome platform status entry lists Web NFC in Chrome on Android only, with no support in Android's WebView, so a page that works in Chrome gets nothing inside such an app.
Those apps reach NFC through a native plugin as well, which leaves them with the same limits as the frameworks above.
What to check before choosing
List the calls the project needs on each platform, then check each one against the plugin before the first line of code: reading and writing NDEF, locking, raw commands per technology, starting the app from a tag, and card emulation where it matters.
Then test on real phones of both platforms. The field behaves the same whatever language called it, and the failures that matter, a tag leaving mid write or a chip refusing a command, only show up there.
Frequently asked questions
Does a framework remove the need for the iOS entitlement?
No. The entitlement belongs to the iOS project the framework builds, as it would for an app written in Swift, and Core NFC requires it before it opens a session.
Can a hybrid app use Web NFC in its WebView?
No. Chrome's platform status entry lists no WebView support for Web NFC, so a hybrid app reaches NFC through a native plugin.
Will a plugin expose host card emulation?
Only if its author wrapped it, and only on Android, where the platform offers it to apps. Card emulation on iPhone depends on Apple's terms rather than on the plugin.
What should I check in a plugin first?
Whether each call the project needs exists on each platform: NDEF read, write and lock, raw commands, starting the app from a tag, and card emulation if it matters. A missing call is cheaper to find before writing code.