React Native Roadmap 2026-W39

Week of September 21–27, 2026

Items This Week

#TitleLabelLink
1React Native RFC — Secondary JavaScript runtimes🟦 RNRead
2ReactLynx — From background rendering to instant first-frame rendering🟦 RNRead
3Reanimated 4.7 — New layout animations engine by default🟦 RNRead
4Secure WebView — explicit origin allowlists and blocked redirects🟦 RNRead
5Enriched Markdown iOS 0.3🟦 RNRead

5-Day Action Plan

 


🟦 RN Chunk 1 — Measure one secondary-runtime workload

Goal: Determine whether an isolated secondary Hermes runtime can improve a real background workload without introducing concurrency risk.

Source: Secondary JavaScript runtimes RFC

Scope:

  • Prototype choose one non-UI workload suitable for background execution.
  • Prototype define message boundaries and cancellation behavior.
  • Prototype prototype the runtime behind a development-only flag.
  • Prototype measure correctness, startup, memory, and failure handling.

Out of scope: Moving application state across runtimes, changing Reanimated internals, and shipping the prototype by default.

Dependencies: A deterministic workload and native build access for the target platforms.

**Acceptance criteria:

  • The workload completes with the same result in the prototype path.
  • Cancellation and errors are observable and do not crash the app.
  • Measurements compare the prototype with the current implementation.
  • The flag defaults off and the recommendation is documented.

Estimated effort: M

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Determine whether an isolated secondary Hermes runtime can improve a real background workload without introducing concurrency risk.

Files to create or modify:

  • src/runtime/secondaryRuntime.ts
  • src/runtime/secondaryRuntime.test.ts
  • docs/secondary-runtime-spike.md

Implementation instructions:

  1. Select a workload with no direct UI or mutable shared object access.
  2. Implement a narrow message-based bridge.
  3. Add cancellation, timeout, and error handling.
  4. Run measurements and record whether the experiment merits continuation.

Acceptance criteria verification checklist:

  • The workload completes with the same result in the prototype path.
  • Cancellation and errors are observable and do not crash the app.
  • Measurements compare the prototype with the current implementation.
  • The flag defaults off and the recommendation is documented.

🟦 RN Chunk 2 — Prototype an instant-first-frame rendering benchmark

Goal: Create a small benchmark that shows whether background rendering techniques improve perceived first-frame time for one screen.

Source: ReactLynx instant first-frame rendering

Scope:

  • Measure select one representative list or content screen.
  • Measure define first-frame and usable-content timestamps.
  • Measure capture baseline and experimental render traces.
  • Measure publish a short comparison with device and build metadata.

Out of scope: Replacing the app renderer, adopting ReactLynx wholesale, and optimizing without a stable baseline.

Dependencies: A deterministic screen fixture and profiling access on at least one representative device.

**Acceptance criteria:

  • The benchmark reports first-frame and usable-content time.
  • Baseline and experimental traces are repeatable.
  • The screen remains functionally correct.
  • The result identifies whether further investigation is justified.

Estimated effort: S

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Create a small benchmark that shows whether background rendering techniques improve perceived first-frame time for one screen.

Files to create or modify:

  • bench/first-frame.ts
  • src/screens/<TargetScreen>.tsx
  • docs/first-frame-benchmark.md

Implementation instructions:

  1. Freeze the fixture data and navigation entry point.
  2. Instrument first render and usable-content milestones.
  3. Capture baseline traces and one experimental rendering variant.
  4. Compare results and document the decision.

Acceptance criteria verification checklist:

  • The benchmark reports first-frame and usable-content time.
  • Baseline and experimental traces are repeatable.
  • The screen remains functionally correct.
  • The result identifies whether further investigation is justified.

🟦 RN Chunk 3 — Validate Reanimated 4.7 layout animations on one screen

Goal: Improve one layout transition while proving that the new default animation engine does not regress reduced-motion or Android behavior.

Source: Reanimated 4.7

Scope:

  • Upgrade select one existing layout animation.
  • Upgrade upgrade or isolate Reanimated 4.7 in the validation branch.
  • Upgrade verify background-image and Android transition behavior only if used.
  • Upgrade add reduced-motion and interruption tests.

Out of scope: A full animation-system migration, new animation design, and unrelated gesture changes.

Dependencies: A screen already using Reanimated and a supported native build.

**Acceptance criteria:

  • The selected transition completes on iOS and Android.
  • Interrupted and reduced-motion states remain usable.
  • No new warning, crash, or stuck layout occurs.
  • The change can be reverted independently.

Estimated effort: M

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Improve one layout transition while proving that the new default animation engine does not regress reduced-motion or Android behavior.

Files to create or modify:

  • src/animations/<TargetTransition>.ts
  • src/screens/<TargetScreen>.tsx
  • src/animations/<TargetTransition>.test.ts

Implementation instructions:

  1. Capture the current transition and accessibility behavior.
  2. Apply the smallest Reanimated 4.7 change in isolation.
  3. Test completion, interruption, background state, and reduced motion.
  4. Compare both platforms and document the result.

Acceptance criteria verification checklist:

  • The selected transition completes on iOS and Android.
  • Interrupted and reduced-motion states remain usable.
  • No new warning, crash, or stuck layout occurs.
  • The change can be reverted independently.

🟦 RN Chunk 4 — Harden one WebView with an origin allowlist

Goal: Reduce redirect and deep-link risk in one security-sensitive WebView flow by failing closed on unexpected origins.

Source: Secure WebView

Scope:

  • Configure list the exact allowed origins and navigation entry points.
  • Configure configure allowlisted navigation and blocked redirects.
  • Configure handle external links through the existing safe browser flow.
  • Configure add tests for allowed, blocked, and malformed URLs.

Out of scope: A complete WebView replacement, authentication redesign, and changing server-side origin policy.

Dependencies: An existing WebView flow with an approved origin list from the product owner.

**Acceptance criteria:

  • Allowed pages load normally.
  • Unexpected origins and redirects are blocked with an understandable message.
  • External links do not silently bypass the policy.
  • Tests cover malformed and deep-link URLs.

Estimated effort: S

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Reduce redirect and deep-link risk in one security-sensitive WebView flow by failing closed on unexpected origins.

Files to create or modify:

  • src/components/SecureWebView.tsx
  • src/security/allowedOrigins.ts
  • src/components/SecureWebView.test.tsx

Implementation instructions:

  1. Agree on allowed origins and external-link behavior.
  2. Wrap the existing WebView with explicit policy checks.
  3. Add blocked-state UI and telemetry without leaking URLs.
  4. Test navigation, redirects, malformed input, and deep links.

Acceptance criteria verification checklist:

  • Allowed pages load normally.
  • Unexpected origins and redirects are blocked with an understandable message.
  • External links do not silently bypass the policy.
  • Tests cover malformed and deep-link URLs.

🟦 RN Chunk 5 — Upgrade one content surface to Enriched Markdown iOS

Goal: Improve rich-text readability and accessibility for one Markdown surface while keeping unsupported content safe.

Source: Enriched Markdown iOS 0.3

Scope:

  • Upgrade identify the supported Markdown constructs on one screen.
  • Upgrade upgrade the iOS renderer or wrapper to Enriched Markdown 0.3.
  • Upgrade preserve typography, links, spoilers, highlights, and math only where needed.
  • Upgrade add VoiceOver and fixture-based verification.

Out of scope: Migrating every content surface, building an editor, full HTML support, and syntax highlighting.

Dependencies: An existing Markdown surface, approved typography tokens, and a fallback for unsupported syntax.

**Acceptance criteria:

  • The selected fixtures render without raw formatting markers.
  • Links and supported rich content remain usable.
  • VoiceOver reads the content in a sensible order.
  • Unsupported syntax has a readable fallback and no crash.

Estimated effort: M

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Improve rich-text readability and accessibility for one Markdown surface while keeping unsupported content safe.

Files to create or modify:

  • src/components/EnrichedMarkdown.tsx
  • src/content/markdownFixtures.ts
  • src/components/EnrichedMarkdown.test.tsx

Implementation instructions:

  1. Inventory the selected screen's Markdown contract.
  2. Upgrade the package and create a typed rendering wrapper.
  3. Add fixtures for supported, unsupported, and partial content.
  4. Verify visual output, links, VoiceOver, and fallback behavior.

Acceptance criteria verification checklist:

  • The selected fixtures render without raw formatting markers.
  • Links and supported rich content remain usable.
  • VoiceOver reads the content in a sensible order.
  • Unsupported syntax has a readable fallback and no crash.