weshipit.today — React Native Newsletter — 2026-W9
Week of February 23–March 1, 2026
Items This Week
| # | Title | Label | Link |
|---|---|---|---|
| 1 | Expo SDK 55 Released | 🟧 EXPO | Read |
| 2 | Ship smaller OTA updates: bundle diffing comes to EAS Update in SDK 55 | 🟧 EXPO | Read |
| 3 | How to upgrade to Expo SDK 55 | 🟧 EXPO | Read |
| 4 | 5 OTA Update best practices every mobile team should know | 🟧 EXPO | Read |
| 5 | The React Foundation Has Launched | ⚛️ REACT | Read |
| 6 | React Native Comes to Meta Quest | 🟦 RN | Read |
| 7 | State of React Native 2025 — Survey Results | 🟦 RN | Read |
| 8 | react-native-enriched-markdown 0.3: GFM + RTL support | 🟦 RN | Read |
| 9 | Creating Query Abstractions with TanStack Query | ⚛️ REACT | Read |
| 10 | Life's Too Short to Hand-Write API Types: OpenAPI-Driven React | ⚛️ REACT | Read |
5-Day Action Plan
🟧 Chunk 1 — Upgrade to Expo SDK 55 with New Architecture
Goal: Migrate the project to Expo SDK 55 (React Native 0.83, React 19.2) and drop the legacy architecture — ensuring the app runs on the latest, fully-supported stack and benefits from all New Architecture performance improvements.
Scope:
- Run
npx expo install expo@55and follow the official upgrade guide - Migrate any legacy architecture-only dependencies to New Architecture equivalents
- Opt into Hermes v1 via
app.jsonconfig flag - Update
metro.config.js,babel.config.js, and any deprecated APIs flagged during upgrade - Run the full test suite and smoke-test on iOS and Android simulators
- Update
CHANGELOG.mdwith breaking changes and resolved deprecations
Out of scope: Expo Router v55 navigation changes (separate chunk), EAS Update bundle diffing (Chunk 2).
Dependencies: None — isolated upgrade branch, no production impact until merged.
Acceptance criteria:
- App builds and runs on both iOS and Android with zero legacy architecture warnings
- React Native version reads
0.83.xin the app'spackage.json -
CHANGELOG.mddocuments every breaking change encountered - A non-technical stakeholder can navigate the full app flow without errors
Estimated effort: M
🟧 Chunk 2 — Enable EAS Update Bundle Diffing for Smaller OTA Payloads
Goal: Reduce OTA update download sizes by up to 75% by activating bundle diffing in EAS Update — directly improving update adoption rates for users on slower networks.
Scope:
- Upgrade
expo-updatesto the SDK 55 version - Enable bundle diffing in
eas.jsonupdate configuration - Push a test OTA update to the
previewchannel and measure the diff size vs. the full bundle - Document the before/after payload size in a
EAS-UPDATE.mdfile - Verify that devices on the
previewchannel receive the patch correctly
Out of scope: Gradual rollout rules, rollback automation (addressed in Chunk 3), production channel rollout.
Dependencies: Expo SDK 55 must be installed (Chunk 1).
Acceptance criteria:
- A test OTA update is received by a device as a diff patch, not a full bundle
- Download size is measurably smaller than the equivalent full bundle (log the delta)
-
EAS-UPDATE.mdrecords baseline vs. diffed payload sizes - No crashes or visual regressions on the updated device
Estimated effort: S
🟧 Chunk 3 — Implement OTA Update Best Practices (Channels, Rollback & Fingerprint)
Goal: Harden the OTA update strategy by applying the 5 best practices published by Expo — giving the team a safe, predictable release process and the ability to instantly roll back a bad update.
Scope:
- Configure
preview,staging, andproductionupdate channels ineas.json - Integrate fingerprint-based update detection using
expo-updatesAPI to prevent mismatched updates - Implement a gradual rollout (10% → 50% → 100%) for the
productionchannel - Add a one-command rollback script to
package.json(npm run update:rollback) - Document the full update workflow in
docs/ota-strategy.md
Out of scope: CI/CD automation of rollouts (future work), A/B testing of update content.
Dependencies: Expo SDK 55 and EAS Update bundle diffing (Chunks 1 & 2).
Acceptance criteria:
- Three update channels exist and are named correctly in the EAS dashboard
- A fingerprint mismatch is gracefully handled (no crash, user prompted to update)
- Gradual rollout is verified by deploying to 10% of the
previewchannel -
npm run update:rollbacksuccessfully points the production channel back to the previous bundle -
docs/ota-strategy.mdis readable by a non-technical stakeholder
Estimated effort: M
🟦 Chunk 4 — Audit Project Stack Against State of React Native 2025 Results
Goal: Benchmark the project's current tooling, libraries, and architecture choices against the community consensus from the State of React Native 2025 survey — identifying gaps and quick wins to align with industry best practices.
Scope:
- Read through the State of React Native 2025 results focusing on: architecture adoption, navigation, state management, testing, and styling sections
- Map each major category to the project's current choice
- Identify 3 "high-retention / high-usage" libraries the project is not yet using
- Write a
STACK-AUDIT.mdwith a two-column table: Current choice vs. Community favourite - Open one follow-up issue per identified gap (labelled
tech-debt)
Out of scope: Implementing the identified changes (tracked as separate issues).
Dependencies: None — purely analytical, no code changes required.
Acceptance criteria:
-
STACK-AUDIT.mdcovers all 5 survey categories with current vs. recommended choices - At least 3 follow-up
tech-debtissues are created - A non-technical stakeholder can read the audit summary in under 5 minutes
- The audit is reviewed and acknowledged by a second team member
Estimated effort: S
⚛️ Chunk 5 — Migrate API Types to OpenAPI-Driven Generation with Hey API + Zod
Goal: Eliminate hand-written API types and frontend/backend type drift by generating all API client types automatically from the OpenAPI specification — reducing bugs and saving hours of manual type maintenance per sprint.
Scope:
- Install
@hey-api/openapi-tsand configure it to point to the project's OpenAPI spec - Generate TypeScript types and a typed fetch client for all existing API endpoints
- Replace the top 3 hand-written type files with generated equivalents
- Add Zod schemas for runtime validation on the 3 most-used API response shapes
- Add a
pnpm generate:apiscript topackage.jsonand document it inREADME.md - Set up MSW handlers using the generated types for existing unit tests
Out of scope: Migrating all API calls in one go (incremental migration), CI enforcement of schema freshness (future work).
Dependencies: An OpenAPI spec (.json or .yaml) must exist or be accessible from the backend team.
Acceptance criteria:
-
pnpm generate:apiruns without errors and produces updated type files - The 3 replaced type files are deleted and replaced by imports from the generated client
- Zod validation catches a deliberately malformed API response in a unit test
- MSW handlers use generated types with no TypeScript errors
-
README.mddocuments the generation workflow for new developers
Estimated effort: M