React Native ecosystem updates: what SDK 56, 0.85, and React 19.2 change

The React Native ecosystem updates around SDK 56, React Native 0.85, and React 19.2 are useful because they move three different parts of a production app forward: native UI, rendering behavior, and build workflows. Expo SDK 56, released May 21, 2026, includes React Native 0.85 and React 19.2, and its most practical additions are stable native UI APIs, universal components, precompiled iOS packages, and faster Android code generation.

The short version for an existing app is not “upgrade everything immediately.” Check your current versions, read the SDK 56 known-regression notes, test native screens on physical devices, and measure clean builds before and after. The release is worth evaluating, but the migration still belongs in a normal engineering ticket with a rollback path.

What changed in the 2026 React Native stack?

Expo’s official SDK 56 release notes describe the relationship clearly: SDK 56 includes React Native 0.85 and React 19.2. SDK 56 also makes Expo UI’s SwiftUI and Jetpack Compose APIs stable, adds universal components for Android, iOS, and web, and includes build-time improvements.

That gives builders three upgrade surfaces:

• Rendering: React 19.2 adds Activity, useEffectEvent, performance tracks, and partial pre-rendering.
• Native interface: SDK 56 adds stable native UI APIs and shared components across platforms.
• Build pipeline: precompiled iOS packages and an opt-in Android code-generation setting reduce some clean-build work.

Keep those surfaces separate in your issue tracker. A rendering regression, a native input bug, and a slower CI build need different evidence and different owners.

What does React 19.2 change for mobile screens?

React 19.2’s Activity component is the most directly useful change for navigation-heavy interfaces. It lets you keep a likely-next screen rendered but hidden, or preserve state when a user navigates away:

import { Activity } from 'react';

export function SettingsTab({ active }: { active: boolean }) {
  return (
    <Activity mode={active ? 'visible' : 'hidden'}>
      <SettingsScreen />
    </Activity>
  );
}

In hidden mode, React hides the children, unmounts effects, and defers updates. In visible mode, it mounts effects and processes updates normally. That makes Activity a better fit for a tab or route cache than a blanket promise that every screen should stay warm.

Use it where preserving state or preparing a predictable next route matters. Do not wrap every subtree without measuring memory and rendering behavior on the devices you support.

useEffectEvent addresses a different problem: an effect that needs current values for an event without reconnecting an external system for every unrelated prop change.

function ChatRoom({ roomId, theme }: Props) {
  const onConnected = useEffectEvent(() => {
    showNotification('Connected', theme);
  });

  useEffect(() => {
    const connection = createConnection(roomId);
    connection.on('connected', onConnected);
    connection.connect();
    return () => connection.disconnect();
  }, [roomId]);

  return <ChatView />;
}

The official React guidance says Effect Events should not be placed in the dependency array and should be declared in the same component or Hook as their effect. Upgrade the hooks lint package before adopting the pattern so the linter understands the rule.

What does SDK 56 add for native UI?

SDK 56 makes Expo UI’s Android and iOS APIs stable and adds universal components intended to share interface code across Android, iOS, and web. The documented component set includes layout primitives, text, inputs, controls, and sheets. Web support is described as experimental, so test it as a separate target rather than assuming native parity.

A shared input can look like this:

import { TextInput } from '@expo/ui';

export function EmailField({ value, onChange }: Props) {
  return (
    <TextInput
      value={value}
      onChangeText={onChange}
      placeholder="you@example.com"
    />
  );
}

The import and props in your installed SDK must match the current package documentation. The important architectural point is that one interface can be evaluated against three platform behaviors instead of maintained as unrelated screen copies.

SDK 56 also includes drop-in replacements for several community components. The release notes warn that most migrations involve changing the import, but some props may differ because the replacements use different native primitives. Treat that as a compatibility review, not a search-and-replace operation.

For every native component you migrate, check keyboard behavior, focus, accessibility labels, safe-area handling, dynamic colors, and automated tests on both mobile platforms. A component that renders is not necessarily a component ready for a release build.

How much faster are SDK 56 builds?

Expo reports two concrete build changes in its SDK 56 notes. Prebuilt iOS frameworks cut median clean iOS build times by around one minute, or about 16%, in Expo’s measurements. The release also reports an Android :app:buildCMakeDebug benchmark falling from 17 minutes 10 seconds to 6 minutes 06 seconds with precompiled headers, a 2.81x reduction for that task. Results vary by project, and Android precompiled headers are opt-in and experimental.

The iOS setting is enabled by default for the precompiled modules described in the release notes. To opt out locally, Expo documents:

EXPO_USE_PRECOMPILED_MODULES=0 npx expo run:ios

For Android, the setting belongs in the build-properties plugin configuration:

{
  "plugins": [
    [
      "expo-build-properties",
      { "android": { "usePrecompiledHeaders": true } }
    ]
  ]
}

Do not carry the benchmark into your own planning as a promise. Capture three measurements instead: clean local build time, clean CI build time, and incremental build time. Record the device or runner class and whether caches were warm. That tells you whether the change helps your bottleneck.

What should you check before upgrading?

Start with a dependency and native-surface inventory:

npx expo-doctor
npx expo config --type public
npm ls react react-native

Use the package manager and commands your repository actually supports. The goal is to identify the current SDK, native modules, config plugins, and custom platform code before changing versions.

Then test in this order:

1. Launch the existing app on a physical Android device and iPhone.
2. Exercise login, deep links, push notifications, keyboard-heavy forms, media, and payments.
3. Upgrade in a branch and run the same flows.
4. Build a release artifact for each platform.
5. Compare startup, navigation, memory, and build timings.
6. Roll back if a native regression cannot be isolated within the ticket’s time budget.

There is one current warning that must not be skipped: Expo’s SDK 56 page records a known Hermes V1 memory regression affecting apps using react-native-worklets and react-native-reanimated, and says it is resolved in SDK 57. If those dependencies are in your app, read the known-regression notes before choosing SDK 56 as your target.

How should an agent handle this upgrade?

Give the coding agent a narrow inspection task first. Ask it to list version constraints, native modules, config plugins, and test commands without editing files:

Inspect this mobile repository for an SDK upgrade.

Report:
- current React, React Native, and SDK versions
- native modules and config plugins
- files that contain platform-specific code
- commands for type checks, tests, and release builds
- known-risk flows: auth, deep links, keyboard, notifications, payments

Do not edit files. Stop if the target version is not specified.

After the inventory, upgrade one layer at a time and keep the diff reviewable. Ask for the lockfile, native project changes, and test output in the handoff. The agent can find all references quickly; it cannot decide whether a memory increase on a low-end phone is acceptable for your users.

The same production boundary appears in background jobs for AI features: make state, retries, and evidence explicit instead of assuming the happy path. For cross-platform architecture, one codebase across three platforms is the relevant comparison point, while React Native 0.86’s upgrade notes show why release claims still need device-level checks.

OTF’s full-stack app templates are one complementary starting point for teams that want shared web and mobile UI, an owned codebase, AI-tool configuration, and deployment scripts before the first feature is delegated. The upgrade decision remains yours; the useful part is having a consistent project structure to inspect.

React Native 0.85, React 19.2, and SDK 56 are worth testing because they improve native UI, rendering control, and build workflows in concrete ways. Treat the releases as three measurable changes, not one magic upgrade: inventory first, migrate in a branch, test real device flows, and keep the regression evidence with the code.

Sources

• Expo SDK 56 — Expo

Originally published at otf-kit.dev — full-stack app templates for web and mobile. See the templates →