← All posts

React Native in 2026: New Architecture, native code, and AI boundaries

A real-app walkthrough: Fabric and JSI, where work runs, bare vs Expo, keyboards on complex forms, and where AI actually helps in RN.

Tags
architectureNewsmobileReactreact native
React Native in 2026: New Architecture, native code, and AI boundaries
Contents

In brief

“One codebase for iOS and Android” is too thin for 2026. A Habr write-up walks a large React Native app: a shared TypeScript product layer, New Architecture without the Legacy Bridge, native slices for system APIs, and honest limits for AI help.

What happened

The team picked RN not to ignore platforms, but to keep shared product logic while shipping iOS and Android in sync. Beside a thousand TS/TSX files live Kotlin and Swift: location, push, biometrics, widgets, media.

New Architecture is no longer experimental: JSI instead of the old Bridge, Fabric, TurboModules, Codegen; 0.84 removed Legacy and made Hermes V1 default. Turning the renderer on does not by itself make an app fast — long JS work and excess re-renders remain.

The author’s main question is not “what language,” but where execution happens: JS for logic, the native UI thread for frames, worklets for gestures, native modules for background work. Kotlin/Swift is not a cross-platform failure if product rules are not duplicated. Expo vs bare is a choice about how much native infra the team will own.

A concrete case: keyboards on complex forms — instead of endless KeyboardAvoidingView fights, the field opens a modal with a simple layout. Plus a warning about diverse Android IMEs and mandatory edge-to-edge.

Why it matters

Mobile RN in 2026 is platform engineering with a shared product core, not “React on a phone.” A version bump is a small Gradle/Xcode/patch migration. AI helps with Android/iOS symmetry, Codegen, and build failures, but poorly invents architecture boundaries or keyboard UX when it only sees the surface.

In practice

  1. Split ownership: JS for product and network, native for system APIs behind a narrow contract.
  2. Do not treat New Architecture as a substitute for release profiling.
  3. For complex forms, consider isolated input (a modal) instead of infinite keyboardVerticalOffset tweaks.
  4. Keep a compatibility matrix for RN / React / Reanimated / SDKs and upgrade in layers.
  5. Give AI symmetry checks and patch diffs; leave layer boundaries to humans.

Takeaway

React Native stays a solid choice when shared logic is large and native work stays local and contractual. Success in 2026 is measured by synced releases and controlled platform differences — not by the absence of Kotlin and Swift in the repo.