weshipit.today — React Native Newsletter — 2026-W12

Week of March 16, 2026 – March 22, 2026

Items This Week

#	Title	Label	Link
1	Expo UI in SDK 55 — Jetpack Compose in beta, reworked SwiftUI APIs	🟧 EXPO	Read
2	react-native-ease — Lightweight declarative animations via platform APIs	🟦 RN	Read
3	Next-gen Expo APIs — MediaLibrary & Contacts get object-oriented rewrite	🟧 EXPO	Read
4	Fast Flow Transform — Strip Flow types 20× faster, remove Babel from RN pipeline	🟦 RN	Read
5	TC39 Temporal reaches Stage 4 — Fix dates in JavaScript for good	⚛️ REACT	Read

Sources: This Week In React #273 (Mar 18, 2026) · React Status #467 (Mar 20, 2026)

5-Day Action Plan

🟧 Chunk 1 — Integrate Expo UI Jetpack Compose Components on Android

Goal: Replace custom or third-party Android UI components with Expo UI's Jetpack Compose beta to get pixel-perfect Material Design 3 components that feel fully native on Android — without writing a line of Kotlin.

Scope:

Upgrade to Expo SDK 55 (if not already done)
Identify 2–3 screens that use heavy custom Android styling or third-party modal/search components
Replace them with Compose equivalents: ModalBottomSheet, DockedSearchBar, and LazyColumn from Expo UI
Align SwiftUI components to the renamed SDK 55 API (DatePicker, Toggle, ProgressView)
Test visually on an Android emulator and a physical device

Out of scope: Custom Jetpack Compose components not yet exposed by Expo UI, iOS-specific SwiftUI-only features.

Dependencies: Expo SDK 55, React Native 0.83+, Android API level 24+.

Acceptance criteria:

Target screens render with native Compose components on Android
SwiftUI component names follow the updated SDK 55 naming convention throughout the codebase
A non-technical stakeholder can distinguish the upgraded screens as feeling "more native" on Android
No visual regressions on iOS after renaming SwiftUI components

Estimated effort: M

🟦 Chunk 2 — Migrate Simple Animations from Reanimated to react-native-ease

Goal: Reduce animation-related JS overhead and eliminate flickering on list screens by replacing trivial Reanimated shared-value animations with react-native-ease's zero-JS-overhead platform API calls.

Scope:

Audit the codebase with the bundled AI migration skill to identify simple animations (opacity, scale, background color, border radius) driven by Reanimated
Migrate at least 3 identified animations to <EaseView animate={...}> declarative syntax
Benchmark frame drop rate on a mid-range Android device before and after the migration
Keep Reanimated for complex gesture-driven or layout animations (not in scope for this chunk)

Out of scope: Gesture-driven animations, shared element transitions, layout animations, full Reanimated removal.

Dependencies: Expo SDK 55 / React Native 0.83+, react-native-ease installed.

Acceptance criteria:

The 3 migrated animations run at a stable 60 fps on a mid-range Android device
No JS-thread animation frames are visible in the Profiler for migrated components
A non-technical stakeholder cannot distinguish the before/after visually
Reanimated is still present and untouched for complex animations

Estimated effort: S

🟧 Chunk 3 — Upgrade to Next-Gen Expo MediaLibrary and Contacts APIs

Goal: Adopt the new object-oriented expo-media-library and expo-contacts APIs (using Shared Objects and Shared Refs) for better performance, simpler querying, and future-proofed native module integration.

Scope:

Update expo-media-library and expo-contacts to their latest SDK 55 versions
Refactor all MediaLibrary.* and Contacts.* call sites to use the new object-oriented API
Replace imperative pagination loops with the new streaming/query patterns where applicable
Write or update tests to cover the migrated API surface
Verify permission flows still work correctly on both iOS and Android

Out of scope: Adding new media features beyond what is currently implemented, video asset handling.

Dependencies: Expo SDK 55, existing usage of expo-media-library or expo-contacts.

Acceptance criteria:

All existing media/contacts functionality works as before after the migration
No deprecated API call sites remain in the codebase (grep check in CI)
Permission prompts appear correctly on both platforms
A non-technical stakeholder can browse contacts and media library without errors

Estimated effort: S

🟦 Chunk 4 — Remove Babel from the React Native Pipeline with Fast Flow Transform

Goal: Eliminate Babel from the React Native build pipeline by replacing Flow-type stripping with fast-flow-transform (20× faster, Rust-based), reducing cold Metro startup time and moving toward a fully Rust-based toolchain.

Scope:

Install fast-flow-transform and configure it as a Metro transformer
Remove babel-jest, @babel/core, and Flow-specific Babel presets from package.json
Validate that TypeScript and JSX files still transform correctly in both dev and production builds
Benchmark Metro cold start time before and after the change
Update CI to remove Babel-specific caching

Out of scope: Removing Babel from non-RN parts of the monorepo (e.g. web/Storybook), migrating custom Babel plugins.

Dependencies: React Native 0.83+, Metro ≥ 0.84, Node.js ≥ 20.

Acceptance criteria:

npx react-native start --reset-cache completes without Babel in the transformer chain
Cold Metro startup is measurably faster (benchmark recorded in the PR)
All CI checks (unit tests, type-check, E2E smoke) pass without Babel
A developer can confirm with metro.config.js that no Babel transformer is referenced

Estimated effort: M

⚛️ Chunk 5 — Adopt the Temporal API for All Date/Time Handling

Goal: Replace Date, moment, and dayjs usages with the new ECMAScript Temporal API (Stage 4, standardized in ES2026) for correct, timezone-aware, and immutable date handling across the app.

Scope:

Install the @js-temporal/polyfill for environments not yet shipping native Temporal
Identify all new Date(), moment(), and dayjs() usages in the codebase
Migrate at least the 3 most complex date logic modules (e.g. scheduling, display formatting, duration calculation) to Temporal's PlainDate, ZonedDateTime, and Duration
Add unit tests for the migrated date logic to confirm timezone-correctness

Out of scope: Full codebase date migration (handle in follow-up chunks), UI date picker components, server-side date handling.

Dependencies: Node.js ≥ 22 (native Temporal) or @js-temporal/polyfill for older runtimes, existing date logic in the codebase.

Acceptance criteria:

The 3 target modules use only Temporal types (no Date, moment, or dayjs imports)
Unit tests pass for edge cases: DST transitions, leap years, cross-timezone comparisons
A non-technical stakeholder sees no change in how dates are displayed in the UI
@js-temporal/polyfill is listed as a dependency and conditionally loaded only where needed

Estimated effort: M