React Native Roadmap 2026-W37

Week of September 7–13, 2026

Items This Week

---

5-Day Action Plan

 

---

🟦 RN Chunk 1 — Prepare a React Native 0.88 release-candidate branch

Goal: Evaluate the 0.88 release candidate without destabilizing the main application branch.

Source: React Native 0.88 RC

Scope:

• Upgrade create a disposable upgrade branch or validation app.
• Upgrade run the supported iOS and Android builds with the current native modules.
• Upgrade record SwiftPM, DevTools, TurboModule, and lifecycle compatibility findings.
• Upgrade document blockers and a go/no-go recommendation.

Out of scope: Merging the release candidate into production, upgrading every dependency, and fixing unrelated native issues.

Dependencies: A reproducible build, representative device/simulator coverage, and a rollback path.

**Acceptance criteria:

• The validation branch builds on the supported platforms or lists exact blockers.
• The team has a written compatibility decision with owners for blockers.
• SwiftPM and lifecycle behavior are explicitly checked.
• The main branch remains unchanged until approval.

Estimated effort: M

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Evaluate the 0.88 release candidate without destabilizing the main application branch.

Files to create or modify:

• docs/rn-0.88-rc.md
• package.json
• ios/
• android/

Implementation instructions:

1. Create the validation branch and capture current versions.
2. Apply the RC using the supported upgrade procedure.
3. Build and smoke-test navigation, native modules, and app launch.
4. Record results and rollback or approval criteria.

Acceptance criteria verification checklist:

• The validation branch builds on the supported platforms or lists exact blockers.
• The team has a written compatibility decision with owners for blockers.
• SwiftPM and lifecycle behavior are explicitly checked.
• The main branch remains unchanged until approval.

---

🟧 EXPO Chunk 2 — Add a clear Expo Go authentication preflight

Goal: Reduce confusion caused by Expo Go's new login requirement by detecting missing authentication before project launch.

Source: Expo Go login requirement

Scope:

• Configure add a development-only preflight command or screen.
• Configure explain when login is required and link to the approved sign-in flow.
• Configure keep local development behavior explicit for iOS and Android.
• Configure document the fallback for development builds and CI.

Out of scope: Changing account policy, storing credentials in the repository, and implementing a custom authentication system.

Dependencies: Expo SDK 57+ tooling and an agreed developer sign-in process.

**Acceptance criteria:

• A signed-out developer receives an actionable message before launch fails.
• A signed-in developer can continue normally.
• No token or credential is logged or committed.
• The documentation explains Expo Go versus development-build behavior.

Estimated effort: S

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Reduce confusion caused by Expo Go's new login requirement by detecting missing authentication before project launch.

Files to create or modify:

• scripts/expo-preflight.mjs
• docs/expo-go-auth.md
• package.json

Implementation instructions:

1. Identify the current Expo start command and failure mode.
2. Add a preflight check or wrapper with safe messaging.
3. Test signed-in and signed-out paths without exposing credentials.
4. Update onboarding and CI documentation.

Acceptance criteria verification checklist:

• A signed-out developer receives an actionable message before launch fails.
• A signed-in developer can continue normally.
• No token or credential is logged or committed.
• The documentation explains Expo Go versus development-build behavior.

---

🟦 RN Chunk 3 — Benchmark the app's navigation startup path

Goal: Choose a navigation strategy based on repeatable cold-start, memory, FPS, and JavaScript measurements rather than anecdotal performance.

Source: React Native Navigation Benchmarks

Scope:

• Measure define one representative navigation flow and device matrix.
• Measure capture cold start, route transition, memory, and frame metrics.
• Measure run the same flow with the current router configuration.
• Measure publish a short baseline and one prioritized optimization.

Out of scope: Replacing the router, benchmarking every screen, and optimizing without a measurable regression target.

Dependencies: A fixed sample app flow, stable build configuration, and at least one Android test device.

**Acceptance criteria:

• The same flow can be repeated by a non-technical tester.
• Results include cold start, memory, FPS, and JS measurements.
• The baseline is stored with build and device versions.
• One optimization hypothesis is selected for a follow-up chunk.

Estimated effort: M

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Choose a navigation strategy based on repeatable cold-start, memory, FPS, and JavaScript measurements rather than anecdotal performance.

Files to create or modify:

• docs/navigation-benchmark.md
• scripts/navigation-benchmark.ts
• e2e/navigation-flow.yaml

Implementation instructions:

1. Freeze the route and data fixtures.
2. Instrument the flow with timestamps and frame metrics.
3. Run repeated measurements on the selected device.
4. Summarize variance and choose the next optimization.

Acceptance criteria verification checklist:

• The same flow can be repeated by a non-technical tester.
• Results include cold start, memory, FPS, and JS measurements.
• The baseline is stored with build and device versions.
• One optimization hypothesis is selected for a follow-up chunk.

---

🟧 EXPO Chunk 4 — Prototype one Expo Modules 2.0 native function

Goal: Assess whether the new annotation-based Expo Modules API can simplify one small native capability without committing the whole app.

Source: Expo Modules 2.0

Scope:

• Prototype select one isolated native function with low business risk.
• Prototype implement it in an experimental module using the 2.0 API.
• Prototype compare call shape and measured latency with the existing implementation.
• Prototype document platform and migration constraints.

Out of scope: Migrating all modules, shipping an experimental API to production, and redesigning the native architecture.

Dependencies: A development build, compatible Expo SDK, and one existing native module suitable for comparison.

**Acceptance criteria:

• The prototype builds in the chosen development environment.
• The same function can be called from JavaScript with typed results.
• Latency and failure behavior are recorded against the current version.
• The recommendation states whether to continue or stop.

Estimated effort: M

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Assess whether the new annotation-based Expo Modules API can simplify one small native capability without committing the whole app.

Files to create or modify:

• modules/example/ExampleModule.ts
• modules/example/ios/ExampleModule.swift
• docs/expo-modules-2.md

Implementation instructions:

1. Pick a small existing native function and define its contract.
2. Implement the annotated Swift/Kotlin module in isolation.
3. Expose a typed JavaScript wrapper and error path.
4. Build, measure, compare, and record the decision.

Acceptance criteria verification checklist:

• The prototype builds in the chosen development environment.
• The same function can be called from JavaScript with typed results.
• Latency and failure behavior are recorded against the current version.
• The recommendation states whether to continue or stop.

---

🟦 RN Chunk 5 — Evaluate QuickJS as a bounded runtime experiment

Goal: Determine whether an alternative JSI runtime could improve startup or memory for one isolated workload without risking the main app.

Source: RN QuickJS

Scope:

• Evaluate select a deterministic JavaScript workload.
• Evaluate run it with Hermes and the QuickJS alpha in a benchmark harness.
• Evaluate compare startup, bundle size, memory, and compatibility.
• Evaluate record a go/no-go decision and known library limitations.

Out of scope: Replacing Hermes globally, shipping the alpha runtime, and benchmarking unrelated application screens.

Dependencies: A native development build and a workload that does not require unsupported Hermes internals.

**Acceptance criteria:

• The same workload runs under both runtimes or documents the failure.
• Startup, memory, bundle, and correctness results are captured.
• The experiment is isolated from production runtime selection.
• The decision includes a rollback path.

Estimated effort: M

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Determine whether an alternative JSI runtime could improve startup or memory for one isolated workload without risking the main app.

Files to create or modify:

• bench/quickjs-runtime.ts
• native/QuickJsExperiment.*
• docs/quickjs-evaluation.md

Implementation instructions:

1. Define the workload and correctness assertions.
2. Integrate the alpha runtime only in the experiment target.
3. Run repeatable measurements on one iOS and one Android target.
4. Summarize compatibility and decide whether further work is justified.

Acceptance criteria verification checklist:

• The same workload runs under both runtimes or documents the failure.
• Startup, memory, bundle, and correctness results are captured.
• The experiment is isolated from production runtime selection.
• The decision includes a rollback path.