chore(mobile): upgrade to Expo SDK 57

[juliusmarminge]

Problem

The mobile client was still on Expo SDK 56 and React Native 0.85, one release behind the current stable Expo stack.

Fix

• upgrade to Expo SDK 57.0.18, React Native 0.86.3, and the matching Expo/native packages
• align the pnpm overrides so the workspace installs a single SDK 57 dependency line
• rebase T3's Metro, gesture-handler, and react-native-screens patches
• remove the React Native Gradle and expo-modules-jsi patches whose fixes are now upstream

Expo SDK 57 release notes: https://expo.dev/changelog/sdk-57

Verification

• vp i --frozen-lockfile
• vp exec expo install --check
• vp run --filter @t3tools/mobile typecheck
• vp run lint:mobile (Swiftlint and Android lint clean)
• vp run --filter @t3tools/mobile test (790 tests passed)
• clean Expo iOS prebuild and CocoaPods install
• iPhone 17 Pro / iOS 27 Simulator: native build, install, and launch succeeded; Metro bundled 9,443 modules; a disposable T3 environment paired and reached Connected

Expo Doctor's SDK version, Hermes, Expo config, Metro config, native tooling, and peer-dependency checks pass. Its overall exit remains nonzero on this pnpm workspace because its npm-based package explanations and file-linked local native modules are reported as issues.

Generated with GPT-5.6-sol in T3 Code using the Codex harness.

---

Note

Medium Risk
Broad native stack bump plus large rebased react-native-screens and Metro source-map patches; regressions are most likely in iOS header/toolbar behavior, gestures, and dev bundling rather than server-side logic.

Overview
Upgrades the mobile app from Expo SDK 56 / React Native 0.85 to SDK 57.0.18 / RN 0.86.3, bumping the matching Expo modules, babel-preset-expo, Reanimated, gesture-handler, screens, and worklets. expo.install.exclude now skips react-native-keyboard-controller so Expo’s installer doesn’t fight the pinned version.

Patches are rebased for the new versions: @expo/metro-config@57 still sanitizes composed source maps (strip invalid Hermes bridge segments before @jridgewell/remapping), react-native-screens@4.26.2 keeps T3’s iOS 26 glass header chrome (center/toolbar items, mail-search toolbar, bar-button identifiers) with Android no-op setters, and gesture-handler 2.32 retains failOffsetY on Reanimated swipeables. Removed patches for @react-native/gradle-plugin@0.85.3 and expo-modules-jsi@56 that are no longer needed upstream.

Workspace pnpm overrides / patchedDependencies point at the SDK 57 dependency line (e.g. @expo/metro-config@57.0.12).

^{Reviewed by Cursor Bugbot for commit 1e2b733. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Upgrade mobile app to Expo SDK 57 and React Native 0.86.3

• Bumps Expo and related packages to 57.x, React Native to 0.86.3, and updates react-native-gesture-handler, react-native-reanimated, react-native-screens, and react-native-worklets to new versions in package.json
• Updates pnpm-workspace.yaml overrides and patchedDependencies to target Expo 57-compatible versions; removes obsolete patches for @react-native/gradle-plugin@0.85.3 and expo-modules-jsi@56.0.10
• Updates the @expo/metro-config patch to sanitize Hermes-only trailer/debug line mappings before composing source maps, producing valid JSON-roundtrippable output
• Renames the react-native-screens patch to 4.26.2 and adds header toolbar items, nested UIMenu support, identifier-based subview updates, and new press event routing across iOS and Android
• Behavioral Change: synchronousShadowStateUpdatesEnabled default changes from false to true in ScreenStackHeaderConfigNativeComponent and ScreenStackHeaderSubviewNativeComponent type declarations within the react-native-screens patch

^{Macroscope summarized 1e2b733.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 61cb6009-d230-4f0a-a7e4-42f0480102b1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.3 KiB	13.3 KiB	−1 B (−0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	0 B (0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−1 B (−0.0%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.6 KiB	55.6 KiB	−44 B (−0.1%)	66.4 KiB	✅
Codex	Live turn messages	11	10	−1 (−9.1%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−13 B (−0.1%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	0 B (0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−13 B (−0.2%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	11	11	0 (0.0%)	21	✅

Baseline: 4669eab · PR result: 1e2b733 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

🟠 High

t3code/patches/react-native-screens@4.26.2.patch

Line 1505 in 6209b24

+ ? prepareHeaderBarButtonItems(headerToolbarItems, 'right')

headerCenterBarButtonItems and headerToolbarItems reuse the 'right' namespace, so their generated button and menu IDs collide with header-right items at the same index/path. Because dispatch searches the right collection first, tapping a center or toolbar control/menu invokes the matching header-right callback instead; prepare these collections with distinct namespaces and handle those namespaces during dispatch.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @patches/react-native-screens@4.26.2.patch around line 1505:

`headerCenterBarButtonItems` and `headerToolbarItems` reuse the `'right'` namespace, so their generated button and menu IDs collide with header-right items at the same index/path. Because dispatch searches the right collection first, tapping a center or toolbar control/menu invokes the matching header-right callback instead; prepare these collections with distinct namespaces and handle those namespaces during dispatch.

[macroscopeapp]

🟠 High

t3code/patches/react-native-screens@4.26.2.patch

Line 321 in 6209b24

+ navitem.leadingItemGroups = [config barButtonItemGroupsFromItems:leftBarButtonItems];

On iOS 26, passing { type: "searchBarPlacement" } through a left, right, or center header prop throws invalidArgumentException. These items reach barButtonItemGroupsFromItems: and are wrapped by fixedGroupWithRepresentativeItem:items:, but UIKit permits search-bar placement items only in toolbarItems; route them exclusively through the toolbar path or exclude them from item groups.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @patches/react-native-screens@4.26.2.patch around line 321:

On iOS 26, passing `{ type: "searchBarPlacement" }` through a left, right, or center header prop throws `invalidArgumentException`. These items reach `barButtonItemGroupsFromItems:` and are wrapped by `fixedGroupWithRepresentativeItem:items:`, but UIKit permits search-bar placement items only in `toolbarItems`; route them exclusively through the toolbar path or exclude them from item groups.

[macroscopeapp]

🟡 Medium

t3code/patches/react-native-screens@4.26.2.patch

Line 527 in 6209b24

+ resolvedSearchTextField = searchBar.searchTextField;

When mailSearchToolbar uses its default useFallbackSearchField value of false with an attached searchController, onSearchTextChange never fires as the user types. The UISearchBar branch does not register an editing-change action for searchTextChangeId; wire the same callback to searchBar.searchTextField in that branch.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @patches/react-native-screens@4.26.2.patch around line 527:

When `mailSearchToolbar` uses its default `useFallbackSearchField` value of `false` with an attached `searchController`, `onSearchTextChange` never fires as the user types. The `UISearchBar` branch does not register an editing-change action for `searchTextChangeId`; wire the same callback to `searchBar.searchTextField` in that branch.

[macroscopeapp]

🟡 Medium

t3code/patches/react-native-screens@4.26.2.patch

Line 708 in 6209b24

+ if (mailSearchToolbarConfig != nil) {

A headerToolbarItems array containing a mailSearchToolbar and ordinary items drops every ordinary toolbar item. This assigns @[] to navigationToolbarConfigs, so the later builder never creates the remaining buttons; remove only the mail-search entry while preserving the other configs.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @patches/react-native-screens@4.26.2.patch around line 708:

A `headerToolbarItems` array containing a `mailSearchToolbar` and ordinary items drops every ordinary toolbar item. This assigns `@[]` to `navigationToolbarConfigs`, so the later builder never creates the remaining buttons; remove only the mail-search entry while preserving the other configs.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This is a broad Expo SDK 57 and React Native 0.86 production-native upgrade, including a changed default for synchronous shadow-state updates and a substantial react-native-screens compatibility patch. The native toolbar/search paths also carry unresolved identifier, placement, callback, and item-retention risks that merit focused review.

Not approved because:

• 4 blocking correctness issues found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}