skip to content

Before upgrading a React Native ride-hailing app that depends on 40 third-party libraries, how do you audit them for New Architecture compatibility?

level: seniorimportance: should knowfreq 42%

answer

  1. pure JavaScript needs no check
  2. React Native Directory's New Architecture flag
  3. codegenConfig in the library's package.json
  4. grep native code for Paper-only APIs
  5. run every screen, read the warnings

basics

~20 s

Drop pure-JavaScript libraries, check each native one's New Architecture status in React Native Directory, its codegenConfig and release notes, then run every flow on the New Architecture and sort libraries into supported, interop-only, broken or replace.

solid answer

~50 s

I start by **triaging**: libraries with no Android or iOS code are unaffected by the architecture and drop out of the audit. For each native library I collect evidence: its **New Architecture status on React Native Directory**, whether its `package.json` declares a `codegenConfig` (a sign it ships specs for Turbo Native Modules or Fabric components), its release notes and maintenance activity, and a search of its native code for **legacy-only APIs** such as Paper `UIManager` calls or classes removed in 0.84 and 0.85. Then I **run it**: every flow of the ride-hailing app (map, booking, payment, trip tracking, push) on the New Architecture, reading DevTools warnings, the `not available in the new React Native architecture` errors and any `Unimplemented component` placeholders. Each library ends up **supported, interop-only, broken, or to be replaced**, with an owner and an action.

code

json · 8 lines
json
{
  "name": "react-native-fare-estimate",
  "codegenConfig": {
    "name": "FareEstimateSpec",
    "type": "modules",
    "jsSrcsDir": "src"
  }
}

go deeper

for a junior

Know that libraries with native code can break on the New Architecture and that React Native Directory shows which ones support it.

for a middle

Describe the evidence per library: directory status, codegenConfig, release notes, and which log messages reveal legacy-only API use at runtime.

for a senior

Run the audit end to end: triage, evidence, full-flow testing on both platforms in release, and a classified table with owners, prioritising payment and trip-tracking paths.

for a principal

Use the audit output to set the upgrade's scope and date: decide which interop-only or abandoned libraries must be resolved before the upgrade and which can follow.

## Why the audit comes before the upgrade Since React Native 0.82 the New Architecture is mandatory, and since 0.84 legacy code is being removed release by release. An incompatible library can no longer be worked around by switching architectures. For a **ride-hailing app** with 40 dependencies, the question is not "will the upgrade compile?" but "which of these libraries can take the app across, and what happens to the ones that cannot?" Answering it before the upgrade turns surprises into a plan. ## Step 1: triage what can be affected The architecture concerns **native code**. A library that is pure JavaScript (date formatting, validation, a state container) runs the same on any architecture. Checking whether a package contains Android or iOS sources, or a podspec, usually shrinks the list considerably. What remains is the real audit set: in a ride-hailing app typically maps, location, payments, push notifications, analytics wrappers, camera or document scanning, and custom UI components. ## Step 2: gather evidence per native library 1. **React Native Directory** (`reactnative.directory`) records whether a library supports the New Architecture. React Native's own announcement pointed teams there for exactly this check. 2. **`codegenConfig` in the library's `package.json`**: libraries that ship Turbo Native Module or Fabric component specs declare it, which suggests first-class support rather than interop. 3. **Release notes and activity**: a stated minimum React Native version, a New Architecture changelog entry, recent releases and responsive issues. 4. **A code search for legacy-only APIs** in its native and JavaScript sources: - Paper-only `UIManager` calls (`createView`, `updateView`, `setChildren`, `manageChildren`, `setJSResponder`); - Android classes removed in 0.84 (for example `LazyReactPackage`, `CxxModuleWrapper`, `OnBatchCompleteListener`) or 0.85 (`CatalystInstanceImpl`); - iOS code that relies on bridge methods, which in the bridgeless runtime reach a proxy that returns nil or does nothing. ## Step 3: run it Evidence is not proof, so exercise the app on the New Architecture, ideally on the target version in a branch: - Walk **every flow**: sign-in, map and pickup selection, fare estimate, booking, payment, live trip tracking, rating, push-driven screens. - Watch the logs: since 0.80 React Native DevTools warns about APIs that will not work on the New Architecture, and Paper-only calls log `'<method>' is not available in the new React Native architecture`. - Look at the screens: an iOS placeholder reading `Unimplemented component: <Name>` means a native component was not found at all. - Build both platforms in **release** too, because native compile errors from removed classes show up at build time. ## Step 4: classify and assign | Status | What it means | Typical action | |---|---|---| | **Supported** | Specs shipped, flows work | Pin a compatible version | | **Interop-only** | Works through the interop layers | Track upstream migration; plan a fallback | | **Broken** | Fails to compile or misbehaves | Upgrade, replace, fork or port | | **Abandoned** | No releases, no maintainer response | Replace before it becomes broken | Each row gets an owner and a decision date. Libraries on the payment and trip-tracking path deserve the strictest treatment, because a silent failure there costs rides. ## Pitfalls in the audit itself - **Trusting a badge alone**: the directory flag is a starting point, not a test of your usage. - **Testing only happy paths**: legacy APIs often sit in edge flows such as a map gesture handler or a payment sheet's error path. - **Ignoring warnings because the app runs**: interop-only is working today, not guaranteed tomorrow. - **Mixing the audit with the version bump**: find library problems first, so upgrade failures are not attributed to the wrong cause. ## Presenting the result The audit is only useful if it changes the upgrade plan. A short report should give: - the count per status, so the scale of the problem is visible at a glance; - the blockers on critical flows (payment, booking, trip tracking) called out separately; - for each interop-only library, the upstream issue or release that would end its dependence on interop; - a proposed order: resolve blockers first, upgrade next, migrate interop-only libraries afterwards. ## Summary Triage out JavaScript-only packages, gather evidence for each native one (directory status, `codegenConfig`, release notes, legacy API usage), run every flow on the New Architecture while reading its warnings, and finish with a table of statuses, owners and actions.

  • A library is marked as supporting the New Architecture, yet your map screen misbehaves after the upgrade. What do you check?
    Which version the directory's claim refers to, and whether you are on it. Then the logs: Paper-only API errors or bridge-proxy warnings point at code paths the claim does not cover. Finally, reproduce with a minimal screen using only that component to separate the library from your own usage.
  • Why build release variants during the audit rather than only running the debug app?
    Native compile problems, such as a library referencing a class removed in 0.84 or 0.85, appear during native compilation of every variant, and release builds also exercise the packaging a real user gets. Running only a debug build against a cached native build can hide problems until CI or a store build fails.

saying these in an interview costs you the question

  • Every one of the 40 libraries needs the same deep native review
  • A New Architecture badge on the directory means no testing is needed
  • If the app launches after the upgrade, every library is compatible
  • Interop-only libraries can be left alone indefinitely
  • Library problems are best discovered after bumping React Native