React Native Roadmap 2026-W30

Implement the following React Native chunk for your mobile app: Configure Expo app variants so dev and production builds can be installed side by side on the same device.

Goal: Use Expo's app variants pattern (https://expo.dev/blog/app-variants-side-by-side) to allow simultaneous installation of development and production builds.

Files to create or modify:

• app.config.js — convert from app.json to dynamic config, read process.env.EXPO_PUBLIC_APP_VARIANT
• eas.json — add env block to each build profile setting EXPO_PUBLIC_APP_VARIANT
• assets/icon-dev.png — duplicate of the app icon with a visual DEV badge overlay
• constants/config.ts — export APP_VARIANT and API_BASE_URL derived from the env variable

Step-by-step implementation:

1. Rename app.json to app.config.js and export a function: export default ({ config }) => ({ ...config, ... }).
2. At the top, read: const variant = process.env.EXPO_PUBLIC_APP_VARIANT ?? 'production';.
3. Return variant-specific values:
   • name: variant === 'development' ? 'MyApp (Dev)' : 'MyApp'
   • ios.bundleIdentifier: variant === 'development' ? 'com.myapp.dev' : 'com.myapp'
   • android.package: same pattern
   • icon: variant === 'development' ? './assets/icon-dev.png' : './assets/icon.png'
4. In eas.json, under build.development.env set EXPO_PUBLIC_APP_VARIANT=development; under build.production.env set EXPO_PUBLIC_APP_VARIANT=production.
5. In constants/config.ts, export API_BASE_URL = variant === 'development' ? 'https://api.dev.myapp.com' : 'https://api.myapp.com'.
6. Build both: eas build --profile development --platform ios and eas build --profile production --platform ios.
7. Install both on the same simulator and verify two distinct icons appear.

Acceptance criteria checklist:

• Two apps install without overwriting each other on the same device
• Dev app shows a visual indicator (different icon or "(Dev)" name suffix)
• Constants.expoConfig.ios.bundleIdentifier returns different values per build
• API base URL resolves to the correct endpoint at runtime in each variant

Implement the following React Native chunk for your mobile app: Automate the release pipeline with EAS Workflows and Expo Updates for continuous delivery (inspired by https://expo.dev/blog/posh-manual-weekly-releases-to-continuous-delivery-with-expo).

Goal: Configure a CI/CD pipeline where JS-only changes ship as instant OTA updates and native changes trigger full EAS Builds — zero manual steps post-merge.

Files to create or modify:

• .eas/workflows/deploy.yml — new EAS Workflow definition
• eas.json — ensure channel is configured per build profile
• app.config.js — ensure expo.updates.url is set correctly

Step-by-step implementation:

1. Install expo-updates: npx expo install expo-updates.
2. Run eas update:configure to generate channel configuration.
3. In eas.json, set "channel": "production" under build.production.
4. Create .eas/workflows/deploy.yml:

on:
  push:
    branches: [main]
jobs:
  deploy:
    steps:
      - uses: fingerprint
      - if: fingerprint.changed
        run: eas build --profile production --non-interactive
      - if: "!fingerprint.changed"
        run: eas update --branch production --message "OTA ${{ github.sha }}"

5. In the EAS dashboard under Notifications, configure a Slack webhook for build failures.
6. Test: merge a one-line JS change → confirm OTA publishes. Merge a new native dependency → confirm full build triggers.

Acceptance criteria checklist:

• OTA update is live within 10 min of a JS-only merge to main
• Fingerprint change triggers a full EAS Build automatically
• Build failure sends a Slack / email notification without any manual check
• No developer action required post-merge for either path

Implement the following React Native chunk for your mobile app: Deferred deep linking with Expo Router (https://expo.dev/blog/deferred-deep-linking-the-right-way).

Goal: Route users to the correct screen after install when they tapped a deep link before the app was installed.

Files to create or modify:

• hooks/useDeferredLink.ts — new hook: captures initial URL → stores in AsyncStorage → navigates post-auth
• app/_layout.tsx — call useDeferredLink after auth state resolves
• __tests__/useDeferredLink.test.ts — unit tests for store / navigate / clear cycle

Step-by-step implementation:

1. npx expo install expo-linking @react-native-async-storage/async-storage
2. Create hooks/useDeferredLink.ts:

import * as Linking from 'expo-linking';
import AsyncStorage from '@react-native-async-storage/async-storage';
import { useRouter } from 'expo-router';

const KEY = 'pendingDeepLink';

export function useDeferredLink(isAuthenticated: boolean) {
  const router = useRouter();

  useEffect(() => {
    Linking.getInitialURL().then(url => {
      if (url) AsyncStorage.setItem(KEY, url);
    });
  }, []);

  useEffect(() => {
    if (!isAuthenticated) return;
    AsyncStorage.getItem(KEY).then(url => {
      if (!url) return;
      AsyncStorage.removeItem(KEY);
      const { path } = Linking.parse(url);
      if (path) router.replace(`/${path}`);
    });
  }, [isAuthenticated]);
}

3. In app/_layout.tsx, call useDeferredLink(isAuthenticated) after the auth check resolves.
4. Write tests mocking Linking.getInitialURL returning a URL, verifying AsyncStorage.setItem is called, then simulating isAuthenticated = true and verifying router.replace is called and the key is removed.
5. Test manually: paste a deep link into Safari on iOS Simulator before launching the app, launch the app, complete onboarding, and confirm you land on the correct screen.

Acceptance criteria checklist:

• Deep link URL is persisted across fresh install
• User lands on the correct screen after completing onboarding/auth
• Pending URL is removed from AsyncStorage after navigation
• Unit tests pass for store, navigate, and clear scenarios

Implement the following React Native chunk for your mobile app: Enable EAS Observe for production monitoring before its August 20, 2026 GA date (https://expo.dev/changelog/eas-observe-moves-to-general-availability-on-august-20).

Goal: Start capturing production crash and performance data in EAS Observe to catch regressions before users report them.

Files to create or modify:

• eas.json — confirm "channel": "production" is set in the production build profile
• app.config.js — ensure expo.updates.url is configured (required for Observe)

Step-by-step implementation:

1. Open the Expo dashboard → your project → Observe tab.
2. Click Enable on the production channel.
3. In eas.json, confirm your production profile has "channel": "production" under updates.
4. Create an alert rule: Alerts → New Rule → JS Crash Rate > 1% → Notify via email/Slack.
5. In a dev build, add a temporary throw new Error('test-observe-crash') behind a hidden gesture (e.g. triple-tap), trigger it, and verify the event appears in the Observe timeline within 60 seconds.
6. Remove the test crash.
7. Share the dashboard link with a non-technical stakeholder and confirm they can read the session data.

Acceptance criteria checklist:

• EAS Observe is enabled on the production channel
• Live session data appears in the dashboard within 60 s of app launch
• Test crash event is visible in the Observe timeline
• Alert rule is active and confirmed to notify on threshold breach
• Non-engineer stakeholder can read session traces without assistance

Implement the following React Native chunk for your mobile app: Upgrade to React 19.2.8 and add server action input validation to patch the DoS vulnerability (https://react.statuscode.com/issues/484).

Goal: Apply the security patch for the DoS vulnerability in React 19 server function endpoints and harden server actions against maliciously crafted requests.

Files to create or modify:

• package.json — bump react, react-dom, @types/react to 19.2.8
• app/actions/exampleAction.ts — add zod schema validation as a reference implementation

Step-by-step implementation:

1. Update dependencies:

npm install react@19.2.8 react-dom@19.2.8 @types/react@19.2.8

2. Run npm test and fix any breaking changes (typically none for a patch release).
3. Install zod if not present: npm install zod.
4. In each server action file, add input validation:

import { z } from 'zod';

const schema = z.object({
  email: z.string().email(),
  message: z.string().max(1000),
});

export async function submitContactForm(input: unknown) {
  const data = schema.parse(input); // throws ZodError on invalid input
  // ... rest of the action
}

5. Wrap the schema.parse call in a try/catch and return a structured error response instead of letting it propagate.
6. Deploy and monitor error rates for 24 hours.

Acceptance criteria checklist:

• react and react-dom are at 19.2.8 in package-lock.json
• All existing tests pass after the upgrade
• At least one server action validates input with a zod schema
• Invalid input returns a structured error, not a 500 crash
• No new errors appear in monitoring within 24 h of deploy