React Native Roadmap 2026-W39
Week of September 21–27, 2026
Items This Week
| # | Title | Label | Link |
|---|---|---|---|
| 1 | React Native RFC — Secondary JavaScript runtimes | 🟦 RN | Read |
| 2 | ReactLynx — From background rendering to instant first-frame rendering | 🟦 RN | Read |
| 3 | Reanimated 4.7 — New layout animations engine by default | 🟦 RN | Read |
| 4 | Secure WebView — explicit origin allowlists and blocked redirects | 🟦 RN | Read |
| 5 | Enriched Markdown iOS 0.3 | 🟦 RN | Read |
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.tssrc/runtime/secondaryRuntime.test.tsdocs/secondary-runtime-spike.md
Implementation instructions:
- Select a workload with no direct UI or mutable shared object access.
- Implement a narrow message-based bridge.
- Add cancellation, timeout, and error handling.
- 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.tssrc/screens/<TargetScreen>.tsxdocs/first-frame-benchmark.md
Implementation instructions:
- Freeze the fixture data and navigation entry point.
- Instrument first render and usable-content milestones.
- Capture baseline traces and one experimental rendering variant.
- 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>.tssrc/screens/<TargetScreen>.tsxsrc/animations/<TargetTransition>.test.ts
Implementation instructions:
- Capture the current transition and accessibility behavior.
- Apply the smallest Reanimated 4.7 change in isolation.
- Test completion, interruption, background state, and reduced motion.
- 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.tsxsrc/security/allowedOrigins.tssrc/components/SecureWebView.test.tsx
Implementation instructions:
- Agree on allowed origins and external-link behavior.
- Wrap the existing WebView with explicit policy checks.
- Add blocked-state UI and telemetry without leaking URLs.
- 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.tsxsrc/content/markdownFixtures.tssrc/components/EnrichedMarkdown.test.tsx
Implementation instructions:
- Inventory the selected screen's Markdown contract.
- Upgrade the package and create a typed rendering wrapper.
- Add fixtures for supported, unsupported, and partial content.
- 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.