I build production apps on Expo and React Native, so I've shipped through this whole run of releases. Here are the 5 changes that actually changed how I work, and the 2 I'm still waiting on. First, the shape of the last two years:

React Native release timeline from 0.76 to 0.87, showing the New Architecture going from default to the only option

1. The New Architecture is the only architecture now

For years the New Architecture (Fabric, TurboModules, no bridge) was an opt-in you toggled and prayed over. That era's over. It became the default for new apps in 0.76, and in 0.82 it became the only option. The escape-hatch flags are now ignored:

# android/gradle.properties
      # This meant something in 0.81. As of 0.82 it does nothing.
      newArchEnabled=false

By 0.84 the legacy architecture code is compiled out of the binary by default, not just frozen. An interop layer still exists so older third-party libraries keep working, but the old runtime is on its way to deletion. The practical effect: synchronous native calls, concurrent React, and smaller binaries are just how apps work now, with no config to get wrong.

2. Hermes V1 is the default engine

Hermes was already the recommended JS engine. In 0.84 the rewritten Hermes V1 became the default on both iOS and Android, with no migration step on your side. You get faster startup and better memory behavior for free by upgrading.

You don't have to trust me on which engine is running. Check it at runtime:

const isHermes = () => !!global.HermesInternal;
      console.log('Hermes:', isHermes()); // true by default on 0.84+

If that logs false after upgrading, something in your build config is overriding it. On a clean 0.84 project it's true.

3. iOS builds got dramatically faster

This is the one my laptop is most grateful for. React Native for iOS now ships as precompiled binaries instead of building the whole core from source on every clean install. It landed experimental in 0.81 (up to 10x faster clean compiles) and became the default in 0.84.

On the Expo side, SDK 54 shipped the same precompiled XCFrameworks. Their own RNTester clean build dropped from about 120 seconds to about 10 seconds on an M4 Max. If your CI clean-build times quietly halved this year, this is why. You don't opt in anymore. You just stop waiting.

4. React 19 and a real React Compiler

React 19 landed in React Native in 0.78, and the follow-on releases kept the version current (19.1, 19.2). The bigger deal is the React Compiler, which reached a stable v1.0 in October 2025 and works for React Native, not just the web.

The compiler memoizes your components automatically, so a lot of manual useMemo and useCallback becomes noise you can delete:

// The old ritual: memoize by hand or re-sort on every render
      const sorted = useMemo(() => sortItems(items), [items]);

      // With the compiler on: write the plain version, it memoizes for you
      const sorted = sortItems(items);

New Expo apps (SDK 54 and later) turn the compiler on by default. Read the caveats before you flip it on an existing app, but the direction's clear: hand-tuned memoization is becoming a thing you do rarely, not a habit.

5. The Strict TypeScript API is the default

React Native's types used to be hand-maintained .d.ts files that drifted from the actual code. As of 0.87 the public API is generated straight from React Native's own source, and the Strict TypeScript API is the default for every project.

The visible consequence: reaching into internal paths is now a type error instead of a footgun.

// This used to "work" by importing from a private path. Now it's a type error:
      import SomeInternal from 'react-native/Libraries/Components/...';

      // Import from the public surface, which is what the types describe:
      import { View, Pressable } from 'react-native';

If your codebase leans on deep imports, upgrading to 0.87 will surface them all at once. That's annoying for an afternoon and correct forever after.

What I'm still waiting for

Two things are announced but not done, and both would remove real friction.

The React Compiler as a true React-Native-wide default. It's stable, and it's on by default for new Expo apps. Everywhere else you opt in by hand, and worse, it's easy to think the compiler is active when the transform never actually ran in your Metro output. Until a bare npx react-native init app ships with it on and verifiable, "stable" still comes with an asterisk for most of the ecosystem.

Swift Package Manager on iOS. SwiftPM support arrived in 0.87, but it's experimental and CocoaPods is still the default. The promise is real (no Ruby, no Bundler, no pod install after every dependency change), and iOS tooling has needed this for years. I want the day CocoaPods is the legacy option, not the required one. We're not there yet.

The takeaway

React Native's 2026 story isn't one flashy feature. It's the boring kind of progress that compounds: the New Architecture stopped being a gamble and became the floor, and the toolchain got faster underneath you. Most of these wins arrive by doing nothing more exciting than bumping your version and deleting code you used to need.

So the biggest win is boring. Get onto a recent release, delete the manual memoization the compiler now handles, and stop opting into things that are already the default. The interesting work is the app you build on top, not the plumbing you no longer have to think about.

I write these from real work at astraedus.dev, where I build apps and tools. Building something, or stuck on something like this? Reach me at astraedus.dev or [email protected].

Get the next one in your inbox → subscribe at astraedus.dev.