React Native Roadmap 2026-W33

Week of August 10–16, 2026

Items This Week

#TitleLabelLink
1React Native Plain Text — faster low-memory text rendering🟦 RNRead
2React Native 0.87 — strict TypeScript API and Swift Package Manager🟦 RNRead
3Convex is now a one-command backend for Expo apps🟧 EXPORead
4Connect Expo in the Claude desktop app🟧 EXPORead
5TanStack Table v9 and Next.js 16.3⚛️ REACTRead

5-Day Action Plan

 

🟦 Chunk 1 — Pilot react-native-plain-text in a high-volume list

Goal: Improve scrolling performance and reduce memory pressure for a text-heavy React Native screen without changing the user-facing design.

Scope:

  • Add react-native-plain-text and verify native installation on the supported platforms.
  • Create a small PerformanceText wrapper that exposes only the styles and props used by the target screen.
  • Migrate one production list or feed screen with at least 100 text rows.
  • Add a development-only render counter or benchmark note so the before/after result is repeatable.

Out of scope: A full-app typography migration, rich-text styling, accessibility redesign, and custom native fork.

Dependencies: A text-heavy list screen already exists; native build tooling is available for the target platform.

Acceptance criteria:

  • The selected list renders the same copy, links, truncation, and accessibility labels as before.
  • Scrolling the migrated screen does not produce visual regressions or native crashes.
  • A documented before/after measurement shows no regression in frame rate or memory for the test dataset.
  • The wrapper falls back to React Native Text when an unsupported prop is passed.

Estimated effort: M

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Improve scrolling performance and reduce memory pressure for a text-heavy React Native screen without changing the user-facing design.

Files to create or modify:

  • src/components/PerformanceText.tsx — constrained wrapper
  • src/screens/<TextHeavyScreen>.tsx — migrate one screen
  • package.json and native dependency files — add the package
  • docs/performance-text.md — record the test method and result

Implementation instructions:

  1. Install the package using the project package manager and complete the native linking step required by the current React Native version.
  2. Implement the wrapper with explicit TypeScript props and a documented fallback for unsupported styles.
  3. Replace only the text nodes in one high-volume list; keep layout, navigation, and data fetching unchanged.
  4. Run the screen with a representative dataset, compare scrolling and memory behavior, and record the result.
  5. Run the existing typecheck and platform build before opening the pull request.

Acceptance criteria verification checklist:

  • The selected list renders the same copy, links, truncation, and accessibility labels as before.
  • Scrolling the migrated screen does not produce visual regressions or native crashes.
  • A documented before/after measurement shows no regression in frame rate or memory for the test dataset.
  • The wrapper falls back to React Native Text when an unsupported prop is passed.

🟦 Chunk 2 — Adopt React Native 0.87 strict API types in one app package

Goal: Catch incorrect React Native API usage earlier by using the generated strict API types introduced in React Native 0.87, without forcing a whole-repository upgrade.

Scope:

  • Upgrade the selected app package to the project-approved React Native 0.87 release.
  • Remove a redundant @types/react-native dependency if the package still declares it.
  • Enable strict React Native API types for the package and fix the bounded set of resulting errors.
  • Add a CI typecheck command for the package.

Out of scope: A complete monorepo upgrade, Swift Package Manager migration, AGP 9 migration, or broad refactor of unrelated type errors.

Dependencies: The app package can be built against React Native 0.87 and has a reproducible lockfile-based install.

Acceptance criteria:

  • The selected package installs cleanly from a fresh checkout.
  • The package typecheck passes with strict React Native API types enabled.
  • No @types/react-native duplicate declarations remain in the selected package.
  • A smoke build launches on at least one target platform and the changed public APIs behave as before.

Estimated effort: M

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Catch incorrect React Native API usage earlier by using the generated strict API types introduced in React Native 0.87, without forcing a whole-repository upgrade.

Files to create or modify:

  • packages/<app>/package.json — React Native and type dependency versions
  • packages/<app>/tsconfig.json — strict type configuration
  • packages/<app>/src/** — bounded type fixes
  • .github/workflows/ci.yml or package scripts — typecheck command

Implementation instructions:

  1. Confirm the project’s supported React Native 0.87 patch version and update only the selected app package.
  2. Regenerate the lockfile, remove duplicate React Native type packages, and run the package typecheck.
  3. Fix only errors caused by strict React Native API declarations; leave unrelated errors as follow-up work.
  4. Run a platform smoke build and verify navigation, text input, and one native module on a real or virtual device.

Acceptance criteria verification checklist:

  • The selected package installs cleanly from a fresh checkout.
  • The package typecheck passes with strict React Native API types enabled.
  • No @types/react-native duplicate declarations remain in the selected package.
  • A smoke build launches on at least one target platform and the changed public APIs behave as before.

🟧 Chunk 3 — Add one Convex-backed Expo feature slice

Goal: Give one Expo screen a typed, reactive backend path so a user can create and reload real data without introducing a broad backend rewrite.

Scope:

  • Install and configure the project-approved Convex Expo integration.
  • Create one typed query and one mutation for a small feature such as notes or tasks.
  • Connect one Expo Router screen to loading, success, empty, and error states.
  • Document the local environment variables and the reset procedure for the development dataset.

Out of scope: Authentication, production data migration, offline synchronization, file uploads, and converting the rest of the application to Convex.

Dependencies: A Convex deployment or approved development backend is available, and the app already has an Expo Router screen suitable for the slice.

Acceptance criteria:

  • A fresh developer can configure the documented environment and start the Expo app.
  • The screen loads typed data from the query and creates one item through the mutation.
  • Loading, empty, error, and retry states are visible and understandable.
  • The feature works after a full reload and does not log unhandled promise or network errors.

Estimated effort: M

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Give one Expo screen a typed, reactive backend path so a user can create and reload real data without introducing a broad backend rewrite.

Files to create or modify:

  • convex/schema.ts — minimal feature schema
  • convex/<feature>.ts — query and mutation
  • app/<route>.tsx — screen integration
  • .env.example and docs/convex-feature.md — setup instructions

Implementation instructions:

  1. Install the integration using the project’s Expo-compatible package command and initialize the development deployment.
  2. Define the smallest schema needed for one feature and add runtime-safe input validation.
  3. Implement the query and mutation with typed return values and clear error handling.
  4. Wire the existing route to the backend while preserving the existing design system and navigation.
  5. Verify the flow in a development build, then document setup and cleanup commands.

Acceptance criteria verification checklist:

  • A fresh developer can configure the documented environment and start the Expo app.
  • The screen loads typed data from the query and creates one item through the mutation.
  • Loading, empty, error, and retry states are visible and understandable.
  • The feature works after a full reload and does not log unhandled promise or network errors.

🟧 Chunk 4 — Connect Expo MCP and commit project guidance

Goal: Make the coding assistant use the project’s actual Expo SDK documentation and local development context, reducing incorrect native implementation choices.

Scope:

  • Install the approved Expo MCP integration for local development.
  • Add or update AGENTS.md, CLAUDE.md, and .claude/settings.json with the project’s SDK, routing, and validation rules.
  • Connect one local Expo development server and verify a screenshot or app-state request.
  • Document how to start and stop the local MCP workflow.

Out of scope: Autonomous production deployments, App Store or Play Store review replies, and replacing the team’s code review process.

Dependencies: A Claude desktop environment with MCP support and an Expo development build are available to the developer.

Acceptance criteria:

  • The documented command starts the Expo development server with MCP enabled.
  • The assistant can retrieve the project’s current Expo SDK guidance or a simulator screenshot.
  • The committed guidance files contain no secrets and match the current package versions.
  • A developer unfamiliar with the setup can reproduce it from the README section.

Estimated effort: S

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Make the coding assistant use the project’s actual Expo SDK documentation and local development context, reducing incorrect native implementation choices.

Files to create or modify:

  • AGENTS.md — project-wide agent rules
  • CLAUDE.md — Claude-specific workflow notes
  • .claude/settings.json — local MCP configuration
  • README.md — setup and troubleshooting

Implementation instructions:

  1. Inspect the project’s Expo SDK, router, package manager, and development-build commands.
  2. Install the Expo MCP package or plugin using the supported project instructions.
  3. Write concise guidance that points tools to the installed SDK version and requires typecheck/build verification.
  4. Start Metro with MCP enabled and verify one read-only request such as a screenshot.
  5. Remove tokens and machine-specific paths before committing the configuration.

Acceptance criteria verification checklist:

  • The documented command starts the Expo development server with MCP enabled.
  • The assistant can retrieve the project’s current Expo SDK guidance or a simulator screenshot.
  • The committed guidance files contain no secrets and match the current package versions.
  • A developer unfamiliar with the setup can reproduce it from the README section.

⚛️ Chunk 5 — Migrate one data table to TanStack Table v9

Goal: Ship a leaner, typed table with predictable sorting and pagination while limiting the migration risk to one user-facing data table.

Scope:

  • Install the project-approved TanStack Table v9 and TanStack Store packages.
  • Create a typed table component with only core rows, sorting, and pagination.
  • Persist table state in a small store and render accessible header and pager controls.
  • Add a focused test suite for sorting, page boundaries, empty data, and row rendering.

Out of scope: Filtering, grouping, column visibility, server-side pagination, and migrating every table in the application.

Dependencies: One existing table and its data contract are identified; React Native-compatible table primitives or existing layout components are available.

Acceptance criteria:

  • The table shows the same records and column labels as the current screen.
  • Tapping a sortable header cycles through ascending, descending, and unsorted states.
  • Previous and next controls disable correctly at the first and last page.
  • The focused tests and TypeScript check pass without console errors.

Estimated effort: M

**Copy/paste this prompt:**

Implement the following React Native chunk for your mobile app:

Goal: Ship a leaner, typed table with predictable sorting and pagination while limiting the migration risk to one user-facing data table.

Files to create or modify:

  • src/components/DataTable.tsx — typed table UI
  • src/stores/tableStore.ts — sorting and pagination state
  • src/components/DataTable.test.tsx — behavior tests
  • package.json — TanStack dependencies and test command

Implementation instructions:

  1. Define the row type and column configuration for the selected table.
  2. Install TanStack Table v9 and TanStack Store, then create the minimal store shape.
  3. Configure only core, sorted, and paginated row models and render the rows with existing UI primitives.
  4. Add accessible controls for sorting and pagination with empty and boundary states.
  5. Run the focused tests, typecheck, and a manual device check of the table interaction.

Acceptance criteria verification checklist:

  • The table shows the same records and column labels as the current screen.
  • Tapping a sortable header cycles through ascending, descending, and unsorted states.
  • Previous and next controls disable correctly at the first and last page.
  • The focused tests and TypeScript check pass without console errors.