weshipit.today — React Native Newsletter — 2026-W08

Week of February 16, 2026 – February 22, 2026

Items This Week

#TitleLabelLink
1WebAssembly Comes to Hermes — Integrate C, C++, Rust into React Native🟦 RNRead
2Expo OTA Updates — The Production Playbook🟧 EXPORead
3Sentry React Native 8.0 — Capture App Start errors and crashes🟦 RNRead
4@react-native-ai/json-ui — On-device Generative UI for local LLMs🟦 RNRead
5React Doctor — AI-powered codebase scan for security, perf & architecture⚛️ REACTRead

Sources: This Week In React #269 (Feb 18, 2026) · React Status #463 (Feb 20, 2026)


5-Day Action Plan


🟦 Chunk 1 — Integrate a Rust Module into React Native via Hermes WASM

Goal: Use the new WebAssembly support in Hermes to run a performance-critical Rust function (e.g. hashing, image processing, encryption) directly inside the JS engine — with zero native module boilerplate.

Scope:

  • Identify one existing bottleneck (or new use case) that would benefit from a WASM-compiled Rust function
  • Write a minimal Rust function, compile it to .wasm with wasm-pack
  • Load and call it from React Native JS code via the Hermes WASM API
  • (Optional) Pre-compile to Hermes bytecode .hbc for faster cold start
  • Measure runtime performance vs. the previous JS implementation

Out of scope: Full native module migration to WASM, Android/iOS platform-specific APIs from WASM, production rollout.

Dependencies: React Native 0.83+, Hermes enabled, Rust toolchain (rustup, wasm-pack), Node.js ≥ 20.

Acceptance criteria:

  • The Rust function executes successfully inside the RN app via WASM on both iOS and Android
  • Performance benchmark (ops/sec or execution time) is documented in the PR
  • No app crashes or memory leaks in a 5-minute soak test
  • A developer can run the WASM build step from a single npm run build:wasm command

Estimated effort: M


🟧 Chunk 2 — Implement a Production-Grade OTA Update Strategy with Expo EAS

Goal: Replace ad-hoc or manual OTA releases with a structured, rollout-controlled update strategy using Expo's production playbook — enabling confident, staged releases without a full app store submission.

Scope:

  • Review and apply Expo's production OTA playbook to the current project
  • Configure update channels: production, staging, and canary
  • Set up a rollout percentage (start at 10%, ramp to 100%) for the next non-critical update
  • Add a runtime update check with a user-facing prompt for critical updates
  • Document the release process in the project README

Out of scope: Native code changes (require store submission), A/B testing via OTA, custom update servers.

Dependencies: Expo SDK 54+, EAS Update configured, existing EAS project ID.

Acceptance criteria:

  • Three update channels (production, staging, canary) exist in eas.json
  • A staged rollout to 10% of users completes without reported regressions
  • Critical update prompt appears on-screen and triggers the update within 3 seconds
  • A non-technical stakeholder can trigger and verify a staging update from the EAS dashboard

Estimated effort: S


🟦 Chunk 3 — Upgrade to Sentry React Native 8.0 and Capture App Start Errors

Goal: Upgrade to Sentry RN 8.0 to unlock App Start error and crash capture — catching bugs that happen during the launch sequence before the JS bundle fully loads, which were previously invisible.

Scope:

  • Bump @sentry/react-native to ^8.0.0
  • Review and apply the v8 migration guide
  • Enable App Start tracing and verify App Start spans appear in the Sentry dashboard
  • Add a beforeSend filter to suppress known non-actionable errors
  • Confirm native crash reports are still captured correctly on both platforms

Out of scope: Sentry Performance monitoring beyond App Start, Session Replay setup, source map upload optimisation.

Dependencies: Expo SDK 54+ or bare RN 0.83+, existing Sentry project with DSN configured.

Acceptance criteria:

  • App Start spans are visible in the Sentry Performance dashboard for a fresh install
  • At least one intentional JS error during startup is correctly captured and attributed
  • No duplicate or ghost events appear after the migration
  • A non-technical stakeholder can open the Sentry dashboard and identify the slowest App Start builds

Estimated effort: S


🟦 Chunk 4 — Add On-Device Generative UI with @react-native-ai/json-ui

Goal: Prototype an AI-powered screen that dynamically renders UI components from a local LLM's JSON output — keeping all inference on-device for privacy and offline support.

Scope:

  • Install @react-native-ai/json-ui (alpha) and configure a local model (e.g. via react-native-executorch or Ollama sidecar)
  • Define a JSON schema that maps to 3–5 existing app components (e.g. Card, Button, List)
  • Build a proof-of-concept screen where the LLM generates a layout from a user text prompt
  • Validate that the generated UI renders without crashing and respects the schema

Out of scope: Cloud-based LLM inference, full app AI integration, custom model fine-tuning, production data handling.

Dependencies: React Native 0.83+, New Architecture enabled, a local GGUF/ONNX compatible model.

Acceptance criteria:

  • The prototype screen renders a LLM-generated layout from a text prompt on a physical device
  • The UI schema prevents unknown or unsafe components from rendering
  • Inference runs fully on-device with no network requests (verified via Charles/Proxyman)
  • A non-technical stakeholder can type a prompt and see a rendered UI response in under 10 seconds

Estimated effort: M


⚛️ Chunk 5 — Run React Doctor on the Codebase and Fix AI-Detected Issues

Goal: Run react-doctor across the entire codebase to surface hidden security vulnerabilities, performance anti-patterns, and architectural smells — then resolve all critical and high-severity findings.

Scope:

  • Run npx -y react-doctor@latest . locally and export the full JSON report
  • Triage findings by severity: fix all Critical and High items; document Medium items as follow-up issues
  • Use Claude Code or Cursor to auto-apply suggested fixes for straightforward issues
  • Add a react-doctor check as a non-blocking CI step (report-only, not failing)
  • Write a brief summary of findings and resolutions in the PR description

Out of scope: Fixing Medium/Low findings in this chunk, architectural refactoring beyond the flagged issues.

Dependencies: Node.js ≥ 18, existing React/RN codebase, CI pipeline (GitHub Actions).

Acceptance criteria:

  • Zero Critical and High severity issues remain after the fix PR is merged
  • The react-doctor CI step runs on every PR and posts a summary comment
  • All auto-applied fixes pass the existing test suite without regressions
  • A non-technical stakeholder can read the scan summary and understand what was improved

Estimated effort: S