React Native and Expo Updates: September 2026

Builder brief

Format

guide

Stack

React Native

Reading time

8 min

The September 2026 mobile-development baseline is clearer than it was earlier this year. React Native 0.87 advances native build requirements and makes the Strict TypeScript API the default. Expo SDK 57 provides a separate, slightly earlier React Native baseline. Google Play's target API deadline now affects new app submissions and updates.

This briefing separates those facts so production teams can plan upgrades without treating every ecosystem release as one migration.

The release map

Area	Current signal	Planning consequence
React Native	0.87 released August 11, 2026	Requires Node.js 22.13+, AGP 9, Kotlin 2+, and Android compile SDK 37
TypeScript	Strict TypeScript API is default in 0.87	Audit imports and type errors before changing the runtime
Expo	SDK 57 uses React Native 0.86	Do not describe Expo SDK 57 as a React Native 0.87 upgrade
Expo runtime	expo@57.0.9 addresses an SDK 56 Hermes V1 regression	Use the current patch when moving from the affected SDK 56 baseline
Observability	EAS Observe is generally available	Production telemetry can become part of the release process
Google Play	New apps and updates must target Android 16 / API 36 from August 31, 2026	Target API 36 is the submission requirement; compile SDK 37 is a separate RN 0.87 toolchain requirement

Versions and policies change. Recheck the linked primary source immediately before an upgrade or store submission.

1. React Native 0.87 is a toolchain migration

React Native 0.87 was released on August 11, 2026. Its impact is broader than a JavaScript package update:

• the Strict TypeScript API is enabled by default;
• Metro 0.87 is included;
• Node.js 22.13 or newer is required;
• Android Gradle Plugin 9 and Kotlin 2 or newer become part of the Android baseline;
• Android projects compile against SDK 37;
• Swift Package Manager support is available experimentally.

Plan this as a controlled native-toolchain migration. Update CI images, local Node versions, Gradle conventions, custom native code, and dependency compatibility before changing the application runtime.

The React Native 0.87 upgrade readiness check provides a focused audit sequence. Teams further behind should start with the React Native upgrade guide.

2. The Strict TypeScript API changes the upgrade order

React Native's Strict TypeScript API exposes a more accurate public surface and reduces accidental reliance on internal types. That is useful long term, but it can surface type errors in application code and libraries during the upgrade.

A safer sequence is:

1. run the existing typecheck and store its baseline;
2. inventory imports from React Native internals or deep package paths;
3. update incompatible libraries before the framework migration;
4. adopt the new types in a dedicated change;
5. run device and release-build tests after the type layer is stable.

Do not silence a broad set of new errors with global type overrides. Each error may identify a dependency or API boundary that also affects runtime behavior.

3. Expo SDK 57 and React Native 0.87 are different baselines

Expo SDK 57 uses React Native 0.86, not 0.87. An Expo application can therefore be current on SDK 57 without having the React Native 0.87 toolchain described above.

That distinction matters when writing an upgrade ticket or comparing libraries. Use the Expo SDK's supported React Native version as the application baseline, then verify each native dependency against that combination. Avoid forcing a React Native version that the Expo SDK does not support.

Expo also notes that expo@57.0.9 resolves a Hermes V1 regression affecting applications upgraded from SDK 56. If that path applies to your project, use the current SDK 57 patch and validate startup, updates, and signed release builds.

4. EAS Observe is an operational capability, not an upgrade checkbox

EAS Observe is generally available. The useful decision is not simply whether to enable it. Decide what production signals your team owns:

• startup and rendering performance;
• crashes and handled errors;
• application and runtime versions;
• affected releases and device classes;
• alert thresholds and incident ownership;
• data collection, consent, and retention boundaries.

Observability is most valuable when a release can be connected to a measurable change and a rollback decision. Add that connection to the release checklist instead of treating the dashboard as a separate tool.

5. Expo Agent should not be part of a forward plan

Expo announced that it was ending the closed beta and winding the Expo Agent project down. Do not make an application roadmap depend on that service. If your workflow used it for prototyping, document the source, build, backend, and testing tools that replace each responsibility.

The broader lesson applies to every AI development service: generated output is valuable only when the team can own, build, test, and migrate it. Use the AI React Native app builder evaluation guide before adopting generated code as a production foundation.

6. Google Play requires target API 36 for current submissions

Google Play's published requirement says that, starting August 31, 2026, new mobile apps and app updates must target Android 16 / API 36. Existing mobile apps must target API 35 or higher to remain available to new users on newer Android versions. Verify the current exceptions and device-category rules in the official target API requirements.

Keep three Android concepts separate:

• targetSdk declares the behavior level your release has tested and opts into;
• compileSdk determines which Android APIs the project can compile against;
• the React Native or Expo toolchain determines which combination is supported.

React Native 0.87 compiling against SDK 37 does not mean Google Play's September 2026 mobile-app submission requirement is target API 37. At this point, the published requirement is target API 36.

Use the Android release build guide to verify the signed artifact and keep store credentials outside the repository.

Dopebase All Access Pass

Get app foundations, admin panels, AI skills, practical guidance, updates, and community support in one membership.

Explore All Access

7. OTA updates remain constrained by the native runtime

An over-the-air update can deliver compatible JavaScript and asset changes. It cannot safely replace a native binary when the native dependency graph, permissions, runtime contract, or store-reviewed capability changes.

For Expo projects:

1. define a runtime-version policy;
2. connect channels to environments deliberately;
3. create a new store build for native changes;
4. test OTA updates against the exact installed runtime;
5. keep a rollback path and monitor the affected release.

The principle is unchanged by faster patch delivery: compatibility must be proven against the binary that is already installed.

8. Upgrade readiness is a dependency graph

Before choosing the upgrade date, inventory:

• navigation, gestures, animation, storage, maps, notifications, and camera libraries;
• custom native modules and build plugins;
• CI runner images, Node versions, JDK, Gradle, Xcode, and CocoaPods;
• New Architecture support and internal React Native imports;
• device coverage and store submission deadlines;
• analytics, crash reporting, OTA runtime versions, and rollback procedures.

Upgrade the blockers in dependency order. A calendar-based version bump without this graph tends to move failures into release week.

A September 2026 action plan

If the app is on Expo SDK 57

• confirm the resolved expo patch and supported React Native version;
• run Expo's dependency and project diagnostics;
• validate Hermes behavior, native modules, OTA runtime compatibility, and signed builds;
• plan React Native 0.87 only through a supported future Expo baseline unless you intentionally own a custom native integration.

If the app is bare React Native

• read the 0.87 release notes and Upgrade Helper diff;
• update Node and Android CI prerequisites first;
• isolate Strict TypeScript API fixes;
• test native dependencies and custom modules;
• validate release binaries on representative devices.

If a Google Play submission is due

• confirm targetSdk 36 and the app's actual runtime behavior on Android 16;
• test edge-to-edge layouts, permissions, background behavior, notifications, billing, deep links, and authentication callbacks;
• submit through an internal track early enough to address policy or binary findings.

Final takeaway

The current ecosystem does not have one universal “latest” configuration. React Native 0.87, Expo SDK 57, and Google Play's target API requirement describe different layers of the application.

Write down each layer, choose a supported combination, and require evidence from typechecks, native builds, devices, observability, and store preflight. That is the reliable path from ecosystem news to a production upgrade.

Need more than a starter?

Turn a proven app foundation into your product.

Start from a proven Dopebase foundation and let our team adapt the design, features, integrations, and launch around your product.

Discuss your custom app