React Native Roadmap 2026-W36

Week of August 31–September 6, 2026

Items This Week

---

5-Day Action Plan

 

---

🟦 RN Chunk 1 — Document the React Native C++ API boundary

Goal: Make native dependency upgrades safer by identifying whether the app or its modules rely on public, framework, or private React Native C++ APIs.

Source: React Native C++ API RFC

Scope:

• Implement inventory native modules and patches that include React Native C++ headers.
• Implement record each dependency's API tier and upgrade risk in a short compatibility document.
• Implement add a CI check or documented command that flags newly referenced private headers.
• Implement add one representative verification fixture for the current native build.

Out of scope: A full C++ migration, replacing third-party libraries, and changing the React Native version.

Dependencies: A working native build and access to the app's iOS/Android native dependencies.

**Acceptance criteria:

• The inventory identifies all app-owned C++ includes and their API tier.
• A reviewer can see which dependencies need migration before the next RN upgrade.
• The check fails clearly when a new private-header reference is introduced.
• The app still builds on the supported platform matrix.

Estimated effort: S

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Make native dependency upgrades safer by identifying whether the app or its modules rely on public, framework, or private React Native C++ APIs.

Files to create or modify:

• docs/react-native-cpp-api.md
• .github/workflows/ci.yml
• scripts/check-rn-cpp-api.mjs

Implementation instructions:

1. Search native sources and installed packages for React Native C++ includes.
2. Classify references using the RFC's public/framework/private model.
3. Create the document and a deterministic checker for app-owned code.
4. Run the checker and native build in CI, then record the baseline.

Acceptance criteria verification checklist:

• The inventory identifies all app-owned C++ includes and their API tier.
• A reviewer can see which dependencies need migration before the next RN upgrade.
• The check fails clearly when a new private-header reference is introduced.
• The app still builds on the supported platform matrix.

---

🟧 EXPO Chunk 2 — Instrument one production screen with EAS Observe

Goal: Give the team a stakeholder-readable performance signal for one important Expo screen and its release version.

Source: EAS Observe

Scope:

• Configure initialize EAS Observe using the existing release configuration.
• Configure track one screen-load span and one meaningful interaction.
• Configure attach route and app-version metadata.
• Configure create one saved dashboard view or query for the signal.

Out of scope: Monitoring every route, backend tracing, alert escalation, and historical data cleanup.

Dependencies: EAS Observe access, an existing Expo/EAS release pipeline, and secure environment secrets.

**Acceptance criteria:

• A production-like build emits the selected screen signal.
• The saved view can filter by route and app version.
• A non-technical stakeholder can identify whether the screen is slow.
• Instrumentation causes no visible UI change or runtime error.

Estimated effort: S

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Give the team a stakeholder-readable performance signal for one important Expo screen and its release version.

Files to create or modify:

• src/observability/observe.ts
• src/navigation/ScreenPerformance.tsx
• docs/observe.md

Implementation instructions:

1. Confirm the app's Expo SDK and release-channel setup.
2. Add initialization behind the existing environment guard.
3. Wrap one screen and interaction with performance events.
4. Build a production-like release and verify the saved view.

Acceptance criteria verification checklist:

• A production-like build emits the selected screen signal.
• The saved view can filter by route and app version.
• A non-technical stakeholder can identify whether the screen is slow.
• Instrumentation causes no visible UI change or runtime error.

---

🟦 RN Chunk 3 — Add a guarded ResizeObserver capability check

Goal: Enable measurement of layout changes with a standards-aligned API while keeping a safe fallback for unsupported runtimes.

Source: ResizeObserver for React Native

Scope:

• Test create a small hook that observes one selected view or content surface.
• Test expose width and height changes through typed state.
• Test use the existing layout callback as a fallback.
• Test add unit tests for observer-supported and fallback paths.

Out of scope: A broad layout-system rewrite, polyfilling every screen, and pixel-perfect redesign.

Dependencies: A target screen whose layout currently depends on repeated measurement or manual polling.

**Acceptance criteria:

• The target screen updates dimensions when its observed content changes.
• Unsupported runtimes use the fallback without crashing.
• Tests cover both capability branches.
• No polling loop or listener leak remains after unmount.

Estimated effort: S

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Enable measurement of layout changes with a standards-aligned API while keeping a safe fallback for unsupported runtimes.

Files to create or modify:

• src/hooks/useResizeObserver.ts
• src/components/MeasuredContent.tsx
• src/hooks/useResizeObserver.test.ts

Implementation instructions:

1. Detect the runtime capability without assuming the flag is enabled.
2. Implement the observer hook with cleanup and fallback behavior.
3. Replace measurement logic in one screen only.
4. Test resize, unmount, and unsupported-runtime scenarios.

Acceptance criteria verification checklist:

• The target screen updates dimensions when its observed content changes.
• Unsupported runtimes use the fallback without crashing.
• Tests cover both capability branches.
• No polling loop or listener leak remains after unmount.

---

🟧 EXPO Chunk 4 — Support image paste in the chat input

Goal: Let users paste images into one Expo chat or composer input without losing normal text-input behavior.

Source: expo-paste-input

Scope:

• Implement add the smallest supported expo-paste-input integration.
• Implement handle pasted images with preview, remove, and upload states.
• Implement preserve keyboard, selection, and text submission behavior.
• Implement add a clear error state for unsupported or oversized images.

Out of scope: Rich media editing, multi-image galleries, OCR, and changes to the upload backend.

Dependencies: An existing chat/composer screen and an upload endpoint or local upload adapter.

**Acceptance criteria:

• Pasting an image shows a preview without inserting a broken URI into text.
• The user can remove the image and continue typing.
• Unsupported and oversized images produce an understandable message.
• Text-only input still behaves exactly as before on iOS and Android.

Estimated effort: M

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Let users paste images into one Expo chat or composer input without losing normal text-input behavior.

Files to create or modify:

• src/components/ChatComposer.tsx
• src/components/PastedImagePreview.tsx
• src/components/ChatComposer.test.tsx

Implementation instructions:

1. Confirm the current Expo SDK compatibility and install the package.
2. Add typed paste handling and normalize the returned image payload.
3. Render preview, remove, loading, and error states.
4. Verify paste and text-only flows on both platforms.

Acceptance criteria verification checklist:

• Pasting an image shows a preview without inserting a broken URI into text.
• The user can remove the image and continue typing.
• Unsupported and oversized images produce an understandable message.
• Text-only input still behaves exactly as before on iOS and Android.

---

🟦 RN Chunk 5 — Adopt Gesture Handler Touchable for one action surface

Goal: Make one high-value button feel consistent across touch, hover, and press states with less custom animation code.

Source: Gesture Handler Touchable

Scope:

• Migrate replace one deprecated or custom button implementation with Touchable.
• Migrate map existing scale, opacity, and underlay behavior to supported props.
• Migrate keep accessibility label, disabled, focus, and test identifiers intact.
• Migrate add interaction tests for press and disabled states.

Out of scope: A design-system-wide button rewrite, new visual language, and unrelated gesture refactors.

Dependencies: A selected action button already covered by the app's navigation or feature tests.

**Acceptance criteria:

• The button provides the same business action as before.
• Pressed and disabled states are visible and understandable.
• Accessibility metadata and test IDs are preserved.
• The screen has no gesture conflict on iOS or Android.

Estimated effort: S

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Make one high-value button feel consistent across touch, hover, and press states with less custom animation code.

Files to create or modify:

• src/components/AppTouchable.tsx
• src/screens/<TargetScreen>.tsx
• src/components/AppTouchable.test.tsx

Implementation instructions:

1. Choose one button with existing custom press feedback.
2. Replace its implementation with Gesture Handler Touchable.
3. Preserve accessibility and analytics callbacks.
4. Run interaction tests and verify the screen on both platforms.

Acceptance criteria verification checklist:

• The button provides the same business action as before.
• Pressed and disabled states are visible and understandable.
• Accessibility metadata and test IDs are preserved.
• The screen has no gesture conflict on iOS or Android.