React Native Developer interview questions

I would stage a separate upgraded binary because Fabric and Bridgeless apply to its whole React Native runtime, not to selected screens or users.

• I would inventory all 180 screens, 46 native dependencies, and 18 custom modules, then prove each dependency in clean iOS and Android Release builds.
• The React Native 0.82-or-later candidate would render every React Native surface with Fabric; route flags could choose compatibility or rewritten screen implementations, but both would use that same renderer.
• Releases 1 through 6 would move the upgraded binary through 500 internal devices, 1%, 5%, 25%, 50%, and 100%, with at least 48 hours of observation before every expansion.
• I would halt if crash-free sessions fell below 99.7%, a critical-flow error rose by more than 0.2 percentage points, or startup p95 regressed over 10%; the React Native 0.81-or-earlier app would remain a separate previous-binary cohort.

I would make each independently mounted React Native flow a Fabric surface and avoid alternating ownership inside one interactive view tree.

• The native checkout shell would own view-controller or Fragment navigation, while each React Native surface would own layout, events, and accessibility below its root.
• Native controls needed inside a surface would be exposed as Codegen Fabric components rather than wrapped through ad hoc view-controller containment.
• Cross-boundary data would use small typed props and events, not shared mutable view references or imperative traversal.
• I would benchmark mount and transition time on 3 device tiers because too many tiny surfaces add initialization cost even when each boundary is technically valid.

I would make the typed Codegen spec the source of truth and evolve it with additive contracts across the 8-release compatibility window.

• Each module would expose a narrow TypeScript spec with explicit nullable values, enums, promise behavior, and structured error codes shared by iOS and Android.
• Codegen output would compile in both native projects in CI, and a generated API diff would reject removed methods or changed field meanings.
• New capabilities would be optional and discoverable through a version or capability method so an older binary can reject unsupported calls safely.
• Synchronous methods would be limited to bounded in-memory work under 2 ms, with storage, network, and permission flows remaining asynchronous.

I would bind every JSI object to the owning runtime and make native frame buffers explicitly reference-counted and cancelable.

• A runtime-scoped host object would own a shared native processor, while work items would hold weak references so teardown prevents late callbacks.
• I would never retain or access jsi::Runtime from camera threads; results would return through the runtime scheduler on the JavaScript runtime thread.
• Frame buffers would be released deterministically after processing, with a bounded queue of 2 frames that drops stale work instead of growing memory.
• Surface unmount would cancel producers, invalidate host objects, and pass a 100-cycle mount and unmount leak test on both platforms.

I would use one process-level React Native host and mount isolated surfaces into the existing native navigation shell only when a React Native route is requested.

• iOS view controllers and Android Fragments would receive typed route inputs and host a surface without owning business state inside the native container.
• The native shell would remain responsible for authentication gates, universal links, Android app links, and platform back navigation.
• I would preload only Hermes and the minimal shell after the first native screen, then defer evaluation of noninitial feature modules already embedded in the binary so React Native does not consume the full 2-second cold-start budget.
• Contract tests would launch all 60 React Native routes from native code and verify return results, state restoration, and process-death recovery.

I would reduce that combinatorial space to risk-based lanes that still exercise every supported boundary before release.

• Every pull request would build the current React Native minor on the minimum and current iOS and Android versions with both Debug and Release native configurations.
• Nightly tests would cover the previous React Native minor, all 3 iOS majors, Android API 26 plus 2 representative modern APIs, and arm64 physical devices.
• Each of the 46 native libraries would record its New Architecture support, minimum OS, Xcode, Gradle, Kotlin, and CocoaPods constraints in a machine-readable manifest.
• A React Native or toolchain upgrade could ship only after native compile, 20 critical end-to-end flows, and a 30-minute soak pass on every high-risk lane.

I would classify each package as pure JavaScript, a legacy native package usable through interop, or a package that needs a TurboModule or Fabric component migration.

• Pure JavaScript packages need no native-architecture rewrite, but I would still test current Hermes behavior, removed APIs, and bundle impact.
• A legacy native module or view may stay temporarily when the target React Native interop layer supports it and clean iOS and Android Release builds plus runtime smoke tests pass.
• I would migrate callable native APIs to TurboModules and native views to Codegen Fabric components only when interop fails, required semantics are unsupported, or measured boundary cost justifies it.
• Every critical package would be mounted, invoked, backgrounded, and torn down for 100 cycles in both Release apps, with an owner and replacement plan before the upgraded binary enters rollout.

I would treat Bridgeless as part of the upgraded New Architecture binary, not as a separate runtime toggle for 10% of users.

• TurboModule calls would return promises or bounded synchronous values, while ordered event streams would carry sequence numbers and documented delivery semantics.
• Shared native state would use its own serial executor, actor, or lock instead of relying on the removed bridge queue as an accidental mutex.
• Clean iOS and Android Release builds would mount, invoke, background, and tear down all 12 packages, including any package temporarily served through the interop layer.
• I would stage the upgraded binary at 1%, 5%, 25%, and 100% for at least 24 hours per step, halting below 99.7% crash-free or above a 0.2-point package-error increase while the legacy app remains a separate store cohort.

I would centralize native version declarations and commit every resolver lock so the same revision produces the same iOS and Android graph.

• CocoaPods versions would live in one podspec or helper with Podfile.lock committed, while Android would use a Gradle version catalog and dependency locking.
• React Native, Hermes, Reanimated, Kotlin, AGP, and the iOS toolchain would move as one tested platform set rather than independent upgrades.
• An automated weekly job would propose grouped updates, compile 2 app variants, and publish dependency graph diffs plus binary-size changes.
• Security fixes would use an expedited lane, but still produce immutable lockfiles and a signed build artifact before reaching 14M users.

I would separate binary rollout from route implementation flags because every React Native surface in the upgraded binary uses Fabric.

• Each of the 30 routes would expose one typed input, output, persistence, and analytics contract for a compatibility implementation and a rewritten implementation that both render through Fabric.
• A cached kill switch could route newly started flows to the compatibility implementation within 10 minutes without changing renderer or downloading native code.
• I would halt distribution of the upgraded binary separately; an installed New Architecture binary cannot become the React Native 0.81-or-earlier legacy binary through a remote flag.
• Additive state schemas and 1,000 switch-and-resume tests would prove both implementations survive process death while the previous store binary remains the native fallback cohort.

I would federate source ownership and build-time packages, not assume web-style runtime downloading is acceptable on mobile.

• The reviewed binary would embed all 9 domain modules, while one shell owns navigation, authentication, design tokens, telemetry, and the native capability contract.
• React, React Native, Reanimated, navigation, and Hermes-facing libraries would be exact host-owned singletons with one approved native dependency set.
• Startup would eagerly evaluate only the shell and initial route; embedded noncritical modules could defer evaluation until navigation with a 200 ms loading-state budget.
• Downloaded JavaScript could update only when current review and runtime policy permits it and only within capabilities already embedded and reviewed; new functionality or native code would require a store binary.

I would make the weekly output a versioned build-time package and accept that production feature activation follows the monthly reviewed host binary.

• Every package would expose one registration entry with routes, required host capabilities, analytics schema version, lifecycle hooks, and a health check.
• CI would test the exact content hash against the current and next host, then the monthly host would embed the approved versions into one signed iOS and Android candidate.
• iOS would not download executable feature modules that introduce or change functionality, and Android native dynamic delivery would use store-managed mechanisms tied to that app version.
• A runtime JavaScript update could address an already reviewed embedded capability only when review policy and runtime compatibility allow it; flags could hide a bad embedded module until the next binary.

I would organize the graph around domain APIs and platform packages, then make forbidden dependency directions fail before compilation.

• Each domain would expose a public index with routes, commands, and data types; deep imports into another domain would be blocked by lint and dependency graph rules.
• Shared packages would be limited to stable concerns such as UI primitives, telemetry, networking, and test utilities rather than business logic used by 2 domains.
• Native packages would declare iOS and Android build inputs explicitly so a JavaScript-only change does not invalidate every native target.
• Affected-graph CI would test changed packages plus reverse dependencies, with a nightly full build guarding mistakes outside the 15-minute lane.

I would keep one immutable product core and express brand variation through validated configuration, generated assets, and platform build settings.

• A schema-checked brand manifest would define semantic tokens, copy bundles, feature entitlements, API endpoints, and allowed navigation entries.
• Bundle identifiers, signing, associated domains, push credentials, and privacy manifests would be generated per brand at native build time.
• Runtime brand switching would cover only capabilities shared by the installed binary, never native entitlements or SDKs absent from that brand build.
• CI would build all 12 brands and run visual, deep-link, and configuration contract tests on at least 2 platforms before publishing the SDK.

I would define semantic tokens once and generate typed React Native, iOS, and Android representations from the same validated source.

• Components would consume roles such as surfacePrimary and textCritical rather than brand color names or raw hex values.
• The generator would reject missing tokens across 12 brands and calculate contrast for all text and state combinations against WCAG AA thresholds.
• Typography and spacing changes would be snapshot-tested in 6 locales because longer copy can expose clipping even when color tokens are correct.
• Theme objects would be memoized and switched at the application boundary so 180 screens do not recompute styles during a frame.

I would make the shell the only navigation authority and let modules register typed, versioned route descriptors.

• Every route would have a stable ID, a schema for serializable parameters, authentication requirements, and an optional result contract.
• Universal links, Android app links, and push targets would normalize into the same internal route intent before any module loads.
• Unknown or retired route versions would fall back to a safe destination and emit a metric rather than crashing during state restoration.
• Contract tests would replay the top 100 external links against the current and previous monthly host builds on iOS and Android.

I would divide dependencies into host singletons, centrally aligned libraries, and truly private leaf dependencies.

• React, React Native, Reanimated, navigation, gesture handling, and the query client would be exact host-owned singletons with no module-bundled copies.
• Common TypeScript libraries would use one workspace version policy, while private pure-JavaScript utilities could vary only if bundle analysis proves isolation.
• Module manifests would declare peer ranges, and publication would fail when a requested range does not intersect the host platform set.
• A quarterly upgrade train would move the singleton set together and require bundle size to stay within a 1 MB regression budget.

I would reject the request as stated because downloaded executable modules cannot be a back door for new app functionality.

• Apple App Store Review Guideline 2.5.2 forbids downloading, installing, or executing code that introduces or changes app features, so the iOS binary must already contain the reviewed capability.
• JavaScript OTA delivery is limited to what current review policy permits, a matching runtime, and behavior within the installed binary's embedded capability contract.
• Android native dynamic features may use Play Feature Delivery, but they remain store-managed artifacts tied to the Play-distributed app version rather than arbitrary downloads.
• The 10-minute path can change flags, configuration, and content or apply a policy-compliant fix; 5 genuinely new executable modules, permissions, SDKs, or native APIs require store review and rollout.

I would evaluate one typed flag at the shell boundary and route newly started checkouts to one of two complete embedded implementations.

• The flag would carry an implementation ID, audience rules, expiry date, and minimum binary capability version, never a URL for downloaded executable module code.
• The last valid signed configuration would be cached for cold start, with the proven checkout as the offline or malformed-config default.
• Exposure would be logged once before checkout begins, with 1% observed for 24 hours, 10% for 24 hours, and 50% for 48 hours before reaching 100%.
• I would halt below 99.9% completion, below 99.7% crash-free sessions, or above a 0.2-point payment-error increase; the kill switch would affect new checkouts without switching an in-flight transaction.

I would define a small versioned module contract and verify every publication against all 3 supported host versions.

• The contract would contain registration, typed routes, capability requirements, lifecycle callbacks, telemetry declarations, and structured failure results.
• Additive fields would be optional with defaults, while removals or changed semantics would require a new major contract and a parallel compatibility adapter.
• Consumer-driven tests from the 3 hosts would run against the candidate module, and host fixtures would run against its current and previous versions.
• Publication would fail on undocumented global state, direct imports from the shell, or native capability calls absent from the declared range.