fix(ios): stop the GeometryReader root from shrinking pages for the keyboard

[seantanys]

Summary

Related to #1099 (keyboard variant, see comment). Follow-up to #1096, which regressed in 9.0.2.

On iOS, pages shrink natively when the keyboard opens, while React Native still lays them out at full height. Anything in the lower part of a page is clipped, and its native frame no longer matches the React Native layout, so taps miss it. onLayout keeps reporting the full height, so nothing on the JS side can compensate.

original

Before (9.0.5)	After (this PR)
pager-before-fix.mp4	pager-after-fix.mp4

reproduction

Before (9.0.5)	After (this PR)
pager-repro-unfixed.mp4	pager-repro-fixed.mp4

What happened

• [iOS] v8 (SwiftUI TabView): pages shrink when the keyboard appears — real devices only #1096 reported SwiftUI keyboard avoidance shrinking pages. fix(ios): prevent SwiftUI keyboard avoidance from shrinking pages #1097 fixed it with .ignoresSafeArea(.keyboard), but was closed in favour of fix(ios): propagate safe area insets to child UIKit views inside PagerView #1085, which only propagates safe-area insets to child UIKit views and has no keyboard handling.
• 8.0.4 still behaved, but by coincidence: the TabView was the root of PagerView.body, and its .ignoresSafeArea() (all regions, keyboard included) covered the whole hierarchy.
• chore: improve ios and maestro tests #1101 (9.0.2) wrapped the TabView in a GeometryReader for the vertical layout and frames every page to proxy.size. .ignoresSafeArea() stayed on the TabView, so the new root still honours the keyboard region. When the keyboard opens, proxy.size.height drops by the keyboard overlap and every page is framed to that.
• fix(ios): keep pages out of the safe area again #1140 (9.0.5) restores disableSafeArea() on the hosting view. That zeroes safeAreaInsets only; SwiftUI's keyboard avoidance is a separate channel, so it does not help here.

Fix

Apply .ignoresSafeArea() to the GeometryReader root as well. Layout is owned by React Native, so the pager should not react to the keyboard at all. The inner modifier on the TabView stays, so the vertical-layout frames are unchanged.

       }
     }
+    .ignoresSafeArea()
     .onAppear {

PageChildViewController.propagateSafeArea() reads insets from the RN screen view, not from the hosting view, so child UIKit insets (#1085, #1142) are unaffected.

Test Plan

What's required for testing (prerequisites)?

iOS simulator or device, New Architecture. A pager inside a container that follows the keyboard with a transform (the common KeyboardStickyView / chat-composer setup). When the pager fills the screen the shrunk area sits under the keyboard, so the bug is invisible there.

What are the steps to reproduce (after prerequisites)?

Added Issue #1096 Keyboard Shrink Repro to the example app and .maestro/issues/issue_1096_keyboard_shrink_repro.yaml:

1. Open the example. A bottom sheet holds a five-row pager and a text input; the sheet lifts with the keyboard.
2. Focus the input.
3. Before: once the keyboard settles, only Row 1 is left and the rest of the page is empty. Row 5's native frame reports y 574pt while React Native lays it out at 372pt, so the Maestro tap lands on the keyboard (last-row taps: 0).
4. After: all five rows stay visible and Row 5 increments the counter, with the keyboard open and after it is dismissed.

Verified

• bun typescript, bun lint and bun test pass.
• The new Maestro flow fails on 9.0.5 without the fix and passes with it (iPhone 17 Pro simulator, iOS 26.2, Release build).
• Full iOS Maestro suite with the fix: 10/12 pass. pager_rtl_example and pager_vertical_basic_example fail in the layout-direction setup step, before any pager code runs: DevSettings.reload() does not take effect in the Release build, so the direction never flips. pager_vertical_basic_example passes when run on its own. RTL is not verified.

Found in a production app (chat mention picker built on react-native-tab-view): on 9.0.5 only the first row of a page survived with the keyboard open; with this change the page matches React Native's layout. Android is untouched.

Compatibility

OS	Implemented
iOS	✅
Android	n/a

Checklist

• I have tested this on a device and a simulator: simulator only (iPhone 17 Pro, iOS 26.2), not on physical hardware
• I added the documentation in README.md: not applicable
• I updated the typed files (TS and Flow): not applicable

[seantanys]

Heads-up: #1149 touches the same spot. It adds .ignoresSafeArea(isVertical ? .all : [], edges: .all) to the GeometryReader root, which covers the vertical case but is a no-op for horizontal pagers (the default, and the case here), so the keyboard shrink stays. The two will conflict on that line. Options:

• merge fix(ios): correct vertical pager layout and scroll edge effects #1149 first and I rebase this to make its root modifier unconditional, or
• fix(ios): correct vertical pager layout and scroll edge effects #1149 drops the isVertical condition on the root modifier, and this PR shrinks to the repro + Maestro flow.

cc @ArekChr

[Copilot]

Copilot review overview

🟢 Approval recommended

The targeted fix is consistent with the SwiftUI layout hierarchy and is covered by a focused regression flow.

Review effort: Balanced
Findings: None

What changed in this PR

Prevents iOS SwiftUI keyboard avoidance from shrinking React Native-managed pager pages.

Changes:

• Makes the root GeometryReader ignore safe areas.
• Adds an iOS keyboard-shrink reproduction screen and Maestro regression test.
• Registers the reproduction in the example app.

File	Description
ios/​PagerView.swift	Prevents keyboard-driven page resizing.
example/​src/​gh-issues/​Issue1096KeyboardShrinkRepro.tsx	Adds the reproduction screen.
example/​src/​App.tsx	Registers the new example.
.maestro/​setup/​issue_1096_keyboard_shrink_repro_setup.yaml	Opens the reproduction screen.
.maestro/​issues/​issue_1096_keyboard_shrink_repro.yaml	Verifies interaction before and after keyboard dismissal.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.