React Native Roadmap 2026-W34

Implement the following React Native chunk for your mobile app:

Goal: Move one production Firebase integration onto the New Architecture-compatible v26 APIs and remove unnecessary asynchronous wrappers from the chosen user flow.

Files to create or modify:

• package.json — selected Firebase package versions
• src/firebase/<feature>.ts — bounded API migration
• src/<feature>/** — call-site updates
• src/firebase/<feature>.test.ts — smoke coverage

Implementation instructions:

1. Inventory the selected feature’s Firebase imports and confirm the v26 migration notes for those APIs.
2. Upgrade only the required packages and regenerate native dependency state.
3. Update call sites, preserving existing error handling and analytics event names.
4. Run the feature on both supported platforms, including one offline or denied-permission case.
5. Record any remaining v25-compatible APIs as separate follow-up work.

Acceptance criteria verification checklist:

• The selected feature builds and launches with the project’s New Architecture configuration.
• The user flow completes successfully on iOS and Android or the project’s supported target.
• A denied permission, offline request, or Firebase error shows the existing safe fallback.
• No deprecated v25 API or unhandled promise warning remains in the migrated feature.

Implement the following React Native chunk for your mobile app:

Goal: Allow the product team to compare two existing paywall offerings and measure conversion outcomes without shipping a new binary for each variant.

Files to create or modify:

• src/paywall/ExperimentPaywall.tsx — variant selection UI
• src/paywall/revenueCatExperiment.ts — offering and fallback logic
• src/analytics/paywallEvents.ts — event payloads
• docs/paywall-experiment.md — dashboard and QA instructions

Implementation instructions:

1. Confirm the two approved offerings and create the experiment in the RevenueCat dashboard.
2. Implement a typed loader that requests the experiment placement and returns the default offering on failure.
3. Reuse the existing paywall component so the experiment changes only the offering data.
4. Add analytics payloads and a QA-only way to force each variant on a test device.
5. Verify purchase, restore, dismissal, disabled-experiment, and offline scenarios.

Acceptance criteria verification checklist:

• A test device receives a deterministic variant assignment.
• The selected variant renders with the existing purchase and restore flow.
• Purchase and dismissal events include the placement and experiment identifiers.
• Disabling the experiment or losing network access falls back to the default offering.

Implement the following React Native chunk for your mobile app:

Goal: Prevent users from losing an activity-tracking session when the app is backgrounded, restarted, or temporarily offline.

Files to create or modify:

• src/activity/activitySession.ts — state model and persistence
• src/hooks/usePersistedActivity.ts — lifecycle integration
• app/activity.tsx — resume and offline UI
• src/activity/activitySession.test.ts — recovery tests

Implementation instructions:

1. Document the minimal session fields and version the persisted payload.
2. Implement atomic save and restore helpers with corrupted-data handling.
3. Subscribe to app lifecycle changes and checkpoint the active session.
4. Add resume, discard, stale, and retry states to the existing activity screen.
5. Test app reload, background/foreground, interrupted save, and malformed payload cases.

Acceptance criteria verification checklist:

• Killing and reopening the app restores an in-progress session without corrupting elapsed time.
• Backgrounding the app saves the latest checkpoint.
• An interrupted write leaves the previous valid checkpoint intact.
• The user can resume, discard, or retry with clear UI feedback.

Implement the following React Native chunk for your mobile app:

Goal: Give the team actionable performance and crash visibility for one Expo production surface before expanding monitoring across the application.

Files to create or modify:

• app.json or app.config.ts — Observe configuration
• src/observability/index.ts — initialization and screen hook
• docs/eas-observe.md — verification runbook
• .env.example — non-secret configuration names

Implementation instructions:

1. Follow the current EAS Observe setup for the project’s Expo SDK and add the package/config plugin if required.
2. Initialize the SDK at the app entry point with environment-safe configuration.
3. Instrument one critical route and one handled error path.
4. Build and distribute an internal release, then verify the trace and release metadata.
5. Document dashboard checks and remove any temporary test instrumentation before merge.

Acceptance criteria verification checklist:

• An internal release reports at least one screen load or navigation trace.
• A deliberately triggered handled error is visible with the correct release identifier.
• No secret or personal token is committed to the repository.
• The runbook lets a stakeholder find the release and the captured signal in the dashboard.

Implement the following React Native chunk for your mobile app:

Goal: Make one high-traffic screen feel correct on each platform by using Expo’s native primitives while preserving the existing feature behavior.

Files to create or modify:

• app/<route>.tsx — screen migration
• src/components/native/<Component>.tsx — shared wrapper if needed
• src/components/native/<Component>.test.tsx — behavior tests
• docs/native-first-screen.md — QA notes

Implementation instructions:

1. Write down the current user journey and identify the one platform mismatch to fix.
2. Implement a small cross-platform wrapper around the selected Expo native primitives.
3. Migrate the screen without changing its data or navigation contracts.
4. Run the existing tests and manually verify keyboard, safe-area, accessibility, and theme behavior.
5. Capture before/after screenshots and document any platform-specific limitation.

Acceptance criteria verification checklist:

• The same user goal can be completed on iOS and Android.
• Controls respect safe areas and platform interaction conventions.
• Existing deep links, loading/error states, and analytics events still work.
• A non-technical tester confirms the screen is usable in both light and dark system themes.