React Native Roadmap 2026-W43

Implement the following React Native chunk for your mobile app:

Goal: Upgrade the existing app to Expo SDK 58 / React Native 0.88 and verify that core user flows remain stable.

Source: https://expo.dev/changelog/sdk-58

Files to inspect and modify:

• package.json and the lockfile
• app.json, app.config.js, or app.config.ts
• eas.json, if present
• Any native files or config plugins reported by the Expo upgrade tooling
• Existing smoke-test or end-to-end files for launch, auth, and navigation

Implementation instructions:

1. Inspect the current Expo, React Native, and Expo module versions and note the baseline.
2. Upgrade Expo to SDK 58 with the repository package manager, then run the official dependency alignment command for the new SDK.
3. Resolve only incompatibilities required for SDK 58, preserving existing application behavior and configuration.
4. Run Expo diagnostics and fix actionable dependency, config-plugin, or native-project errors.
5. Build internal iOS and Android artifacts.
6. Run a short smoke test covering launch, authentication, primary navigation, and the main data screen.
7. Document any known follow-up that is outside this chunk.

Verification checklist:

• Expo SDK 58 and React Native 0.88-compatible versions are locked.
• Diagnostics report no blocking errors.
• iOS internal build installs and launches.
• Android internal build installs and launches.
• Launch, auth, navigation, and main data-screen smoke tests pass.

Implement the following React Native chunk for your mobile app:

Goal: Configure a safe EAS Update canary and rollback workflow for JavaScript, styling, and asset-only fixes.

Source: https://expo.dev/blog/teamreach-ota-updates-relaunch

Files to inspect and modify:

• eas.json
• app.json or app.config.*
• package.json
• Existing release documentation, such as README.md or docs/release.md
• CI workflow files only if the repository already publishes EAS Updates there

Implementation instructions:

1. Inspect the current EAS project, runtime version, update URL, branch, and channel configuration.
2. Define a canary channel for internal builds and a stable channel for production without changing the existing production behavior until verified.
3. Add concise package scripts or documented commands for publishing a canary update, promoting a verified update, and rolling back or republishing the last known-good update.
4. Publish a harmless visible test change to the canary channel and confirm it is received by an internal build after restart.
5. Roll back or republish the known-good update and confirm the build returns to the previous behavior.
6. Document the native-code boundary: any native dependency or runtime change requires a new build and store review.

Verification checklist:

• Canary and stable channels are unambiguous.
• The test update reaches only the canary build.
• The update identifier and visible test change are confirmed on-device.
• Rollback or republish restores the known-good bundle.
• Release documentation is complete and warns against OTA-shipping native changes.

Implement the following React Native chunk for your mobile app:

Goal: Create a feature-flagged React Native Skia 3 Graphite pilot for one representative visual and measure whether it is safe to continue.

Source: https://www.thereactnativerewind.com/issues/the-great-graphite-migration-derek-joins-fat-fighters-and-a-leaderboard-for-your-dependency-tree

Files to inspect and modify:

• package.json and the lockfile
• The app config and native build configuration
• src/features/skia-pilot/SkiaPilotScreen.tsx or the project’s equivalent feature directory
• The existing component being used as the comparison baseline
• The project’s feature-flag configuration
• docs/performance/skia-pilot.md or an equivalent engineering note

Implementation instructions:

1. Inspect the app’s current rendering component and identify the smallest useful visual to reproduce.
2. Add the React Native Skia 3 dependency and required native setup without changing unrelated rendering code.
3. Implement an isolated pilot screen that reproduces the selected visual with a clear loading and error state.
4. Gate the screen behind an existing feature-flag mechanism, or add the smallest local flag consistent with project conventions; default it to off.
5. Measure the baseline and pilot on one iOS and one Android device, recording frame smoothness, first render time, and any memory or crash issue.
6. Document the result and an explicit next step.

Verification checklist:

• The app builds on both target platforms.
• The pilot is off by default and existing screens are unchanged.
• The pilot visual is visible when the flag is enabled.
• Baseline and pilot measurements are recorded with device details.
• A continue/revise/remove recommendation is documented.

Implement the following React Native chunk for your mobile app:

Goal: Verify one high-traffic shared route on React Native Web and fix one focused parity issue.

Source: https://thisweekinreact.com/newsletter/301

Files to inspect and modify:

• The selected route under src/, app/, or pages/
• Shared components rendered by that route
• package.json and the existing web-start/test configuration
• A focused component or end-to-end test file
• docs/testing/platform-smoke.md or the project’s equivalent checklist

Implementation instructions:

1. Inspect the repository and select a high-traffic route with representative navigation, buttons, text input, and loading/error states.
2. Run the existing web target and record the first reproducible parity issue.
3. Fix only that issue using shared React Native-compatible code; avoid a web-only redesign.
4. Add a focused regression test when the project’s test setup supports it.
5. Verify the route on web with pointer and keyboard input, then run the same smoke path on iOS or Android.
6. Document the exact commands and manual checks.

Verification checklist:

• The selected route loads on React Native Web.
• There are no console-blocking errors on the smoke path.
• Navigation and primary controls work with pointer and keyboard input.
• The focused parity regression is fixed and tested where practical.
• The mobile/web smoke checklist is documented.

Implement the following React Native product-release chunk for your mobile app:

Goal: Prepare an iOS 27 App Store creative asset pack that can be reviewed and uploaded without a new app build.

Source: https://neoads.substack.com/p/app-store-creative-assets

Files to inspect and modify:

• Existing store-artwork or marketing-assets directory
• Current screenshot source files or capture scripts
• docs/release/app-store-assets.md or the project’s equivalent release checklist
• A new asset manifest such as docs/release/ios-27-assets.json

Implementation instructions:

1. Inspect the current brand assets and screenshot-generation workflow.
2. Create one static product-page header and one static search-results asset aligned with the app’s current visual language.
3. Re-export the required iPhone screenshot at 1206 × 2622 and verify text contrast, safe areas, and legibility.
4. Name files consistently and create a manifest listing placement, dimensions, target OS, message hypothesis, and review status.
5. Upload the assets to an App Store Connect draft when access is available; otherwise deliver the complete upload-ready package and exact upload steps.
6. Do not change app code or claim performance impact from the assets.

Verification checklist:

• Header asset is present and mapped to the product-page placement.
• Search-results asset is present and mapped to the search placement.
• Screenshot is exactly 1206 × 2622 and readable.
• Manifest includes dimensions, placement, hypothesis, and status.
• Assets are uploaded to a draft or delivered as a complete upload-ready package.