React Native NFC Manager: Fix Android Tag Scanning Issues

How Do You Handle Device-Specific NFC Failures in Logistics Apps?

During a recent project for a global supply chain client, we were tasked with modernizing their warehouse logistics and asset tracking platform. The core requirement was seamless operations: warehouse staff needed to instantly read high-value asset data by tapping their mobile devices against physical tags. To achieve this across their diverse fleet of devices, we utilized react native nfc manager to build a cross-platform solution.

Initially, development went smoothly. Background tag scanning worked flawlessly on iOS devices (like the iPhone 17 Pro Max) and select Android models (like the Samsung Fold Z5 and OnePlus 7 PRO). However, as we expanded testing to a broader range of corporate-issued physical devices, we hit a wall. Certain modern Android devices—specifically models like the Samsung S24, S20 FE, A53 and Google Pixel 9A—were silently failing to read the exact same tags. The devices would vibrate, but the app registered nothing.

In a high-throughput logistics environment, a 30% failure rate on tag scans is a critical production blocker. We realized that relying on default background discovery behavior was exposing deep hardware-level fragmentation within Android’s NFC stack. This challenge inspired this article so other engineering teams can avoid the pitfalls of generic NFC implementations and understand what it takes to build truly reliable hardware integrations.

Why Did React Native NFC Manager Fail on Specific Hardware?

The business use case dictated that users should not have to manually press a “Scan” button every time they approached a pallet. The application needed to listen for tags passively in the background while the screen was active. To achieve this, the initial architecture utilized generic tag discovery event listeners.

Here is the sanitized version of the generic implementation we initially used:

  useEffect(() => {
    if (Platform.OS !== "ios" && isNfcAvailable) {
      let isActive = true;
      NfcManager.setEventListener(NfcEvents.DiscoverTag, async (tag) => {
        if (!isActive) return;
        
        if (tag?.ndefMessage?.[0]) {
          processAssetData(tag);
        } else {
          handleScanError();
        }
      });
      NfcManager.registerTagEvent();
      return () => {
        isActive = false;
        NfcManager.setEventListener(NfcEvents.DiscoverTag, null);
        NfcManager.unregisterTagEvent();
      };
    }
  }, [isNfcAvailable]);

The NFC tags in use supported dual technologies: android.nfc.tech.IsoDep and android.nfc.tech.NfcA. While the generic registerTagEvent() handled these tags perfectly on older Android devices and iPhones, the newer fleet of devices struggled with the technology handshake. The issue lived at the intersection of the React Native wrapper, Android’s Intent dispatch system and the physical NFC Controller Interface (NCI).

What Went Wrong with Android Tag Discovery?

To diagnose the silent failures, we connected the problematic devices (like the Samsung A53) and monitored the ADB (Android Debug Bridge) system logs during a tag scan attempt. We found a recurring hardware-level rejection:

E libnfc_nci: nfaConnectionCallback: NFA_SELECT_RESULT_EVT error: status = 5
E libnfc_nci: nfc_ncif_proc_deactivate - evt_data.deactivate.reason 0
E libnfc_nci: NfcTag::selectNextTagIfExists: only found NFC-DEP technology.
E [NFC_SE]SamsungExtension: onTagConnected = false
E [NFC_SE]SamsungExtension: onTagConnected = true
E [NFC_SE]SamsungExtension: onTagConnected = true
E libnfc_nci: nfaConnectionCallback: NFA_SELECT_RESULT_EVT error: status = 5

These logs revealed the true bottleneck. The NFA_SELECT_RESULT_EVT error: status = 5 indicates a protocol collision or timeout within the NCI stack. The NFC controller detected the tag but failed the ISO-DEP activation phase. Because the generic registerTagEvent() relies on Android’s default intent dispatch rather than the newer Android Reader Mode API, the operating system was failing to negotiate between IsoDep and NfcA technologies fast enough, causing the connection to drop before it reached the React Native JavaScript thread.

How Did We Approach the Tag Discovery Solution?

When you are looking to hire software developer talent for hardware-intensive mobile projects, you need engineers who can navigate beyond JavaScript and into native operating system behaviors. We evaluated several approaches to resolve this collision:

Did Android Manifest Intent Filters Help?

We first considered explicitly declaring TECH_DISCOVERED intent filters in the AndroidManifest.xml, explicitly listing IsoDep and NfcA. While this routed the OS-level intents better, it still did not solve the status = 5 NCI error because the hardware controller was still using legacy polling loops.

Could We Use Polling Delay Overrides?

We considered configuring the NFC polling presence delay at the native level to give the tag more time to respond. However, modifying base NFC controller timings requires root access or specific OEM MDM APIs, which was not feasible for standard corporate BYOD or generic company devices.

Did Switching to the Reader Mode API Fix It?

We evaluated abandoning generic background intents and forcing Android into “Reader Mode” using explicit technology requests. By invoking NfcManager.requestTechnology() with specific tech types, Android bypasses the legacy Intent dispatch system and commands the NFC chip to exclusively poll for the requested protocols. This prevents technology collisions and provides direct connection control to the app.

How Did We Implement the Final NFC Tech Request?

The winning solution was to refactor our background listening approach. Instead of generically registering for any tag event, we explicitly requested the technologies our tags used. We managed the background state by initiating the technology request and silently keeping it alive, handling the connection lifecycle explicitly.

Here is the refactored, robust implementation:

  useEffect(() => {
    if (Platform.OS === "ios" || !isNfcAvailable) return;
    let isActive = true;
    const startNfcListener = async () => {
      try {
        // Explicitly request specific technologies to enforce Android Reader Mode
        await NfcManager.requestTechnology([NfcTech.IsoDep, NfcTech.Ndef], {
          alertMessage: 'Ready to scan logistics asset tags'
        });
        if (!isActive) {
          NfcManager.cancelTechnologyRequest();
          return;
        }
        const tag = await NfcManager.getTag();
        
        if (tag) {
          processAssetData(tag);
        } else {
          handleScanError();
        }
      } catch (error) {
        console.warn("NFC Technology Request Failed", error);
      } finally {
        // Clean up and restart loop for continuous background-like scanning
        await NfcManager.cancelTechnologyRequest();
        if (isActive) {
          setTimeout(startNfcListener, 1000); 
        }
      }
    };
    startNfcListener();
    return () => {
      isActive = false;
      NfcManager.cancelTechnologyRequest();
    };
  }, [isNfcAvailable]);

Validation Steps:

We deployed this fix across the fragmented test suite. By strictly defining NfcTech.IsoDep, the NFC controller on the Samsung A53 and Pixel 9A no longer attempted broad discovery loops. The NFA_SELECT_RESULT_EVT status 5 errors vanished from the ADB logs and scan reliability jumped to 100% across all physical hardware.

What Can Engineering Teams Learn from Mobile Hardware Fragmentation?

Solving this issue reinforced several critical principles for mobile engineering teams:

• Never Trust Generic APIs for Hardware: High-level wrappers like generic event listeners are great for prototyping, but production-grade hardware integrations require explicit, strictly-typed commands (like requesting specific NFC technologies).
• Analyze Native Logs Immediately: When cross-platform frameworks fail silently, always drop down to ADB or Xcode logs. The root cause is rarely in the JavaScript thread.
• Understand OS-Level Abstractions: Knowing the difference between Android’s legacy Intent Dispatch and the modern Reader Mode API was the key to this fix.
• Test on Fragmented Hardware Early: Emulators cannot simulate OEM-specific NFC controllers. Procure devices with different chipsets (NXP, Broadcom, Samsung LSI) early in the development cycle.
• Design for Graceful Retries: As seen in our final implementation, wrapping the NFC request in a controlled, continuous loop ensures that even if a transient collision occurs, the app recovers instantly.

If your organization wants to hire react native developers for enterprise mobile apps, ensure they possess the maturity to debug NCI errors and handle hardware fragmentation natively.

How Can You Ensure Reliable Mobile Implementations?

Hardware fragmentation remains one of the largest hurdles in mobile enterprise development. What begins as a simple requirement—scanning a tag—can quickly unravel into complex protocol collisions when deployed across a diverse fleet of devices. By moving away from generic background listeners and explicitly configuring the NFC Reader Mode, we transformed a failing module into a highly reliable logistics tool.

Engineering maturity is defined by the ability to drill down through the abstraction layers, identify the core physical constraint and design a scalable software workaround. If your organization is facing similar challenges or if you need to hire app developer to create a mobile app that seamlessly interacts with custom hardware, enterprise IoT or complex data workflows, contact us. When you hire developers from our dedicated teams, you gain partners who solve the hard problems.

Social Hashtags

#ReactNative #ReactNativeNFC #NFCManager #AndroidDevelopment #NFCScanning #ReactNativeDevelopment #MobileAppDevelopment #EnterpriseMobility #LogisticsTechnology #AssetTracking #SupplyChainTech #IoTDevelopment #AndroidNFC #NFCDebugging #IsoDep #AndroidReaderMode #MobileEngineering #TechSolutions