Expo SDK 55 Bottom Sheet Component: The Settled Answer

What is settled, and what is still craft?

The library is settled: @gorhom/bottom-sheet (1,849,266 weekly npm downloads) over Reanimated and Gesture Handler is the ecosystem’s answer, installing clean in Expo’s managed workflow in the current SDK era, no config drama, the dependencies riding the standard babel plugin setup. What remains unsettled is everything the library cannot decide for you: where the detents live, how the keyboard negotiates, how scrolling hands off, and what the sheet owes assistive tech, which is the actual content of this guide.

How do snap points become detents that mean something?

By mapping to content stages:

Detent	The content state	Why	Verdict
Peek (~15-20%)	The summary that invites	The sheet announces without occluding	One line + handle; tappable to rise
Mid (~50%)	The working set	Most interactions live here	The default landing for presents
Full (~90%+)	Everything, including inputs	Keyboard-needing work	Where text entry belongs
Dynamic	Content-fitted	Short confirmations, menus	Size-to-content beats arbitrary stops

Stops that correspond to real states feel like UI; arbitrary 25/50/90 stops feel like a slider. The map-over-sheet pattern, peek showing the selected place, mid showing details, full showing reviews, is the canonical worked example, and the draggable map-modal entry covers that pairing’s specifics. Backdrop behavior stays predictable: dim behind, tap-to-dismiss at lower detents, and the sheet’s own drag as the primary navigation between stops.

What are the two classic fights, and their resolutions?

The keyboard. A text input inside a sheet summons a keyboard that collides with the sheet’s positioning, the category’s classic pain, resolved by the library’s keyboard behaviors (extend, fillParent, interactive) with the working pattern being inputs live in the full detent and the sheet extends as the keyboard rises, never a mid-detent input pushing the sheet into spasms. Real-device testing is mandatory; the simulator’s keyboard timing lies, in React Native generally and in sheets especially.

The scroll handoff. Scrollable content inside a sheet uses the library’s prefixed components (BottomSheetScrollView, BottomSheetFlatList), which negotiate the gesture boundary: a scroll gesture at the list’s top hands off to the sheet’s drag, mid-list it scrolls the list, and the sheet never fights its own content. Plain ScrollView inside a sheet is the classic generated mistake, the gestures fight and the sheet feels broken, worth a line in the rules file: “scrollables inside sheets use the BottomSheet-prefixed components.” The animation layer underneath inherits the Reanimated discipline, versions pinned, babel plugin configured, transforms only.

What does the accessibility floor require?

Three duties demos skip. Focus moves in: when the sheet presents, screen readers land on its content, not the dimmed page behind. Dismissal beyond the swipe: a visible close affordance and escape semantics, because a sheet reachable and leavable only by gesture is a wall for switch-control and screen-reader users. The background yields: content behind the sheet hides from assistive tech while the sheet owns the stage, then returns on dismiss. The three together are what makes a sheet a modal surface rather than a decoration floating over an active page.

The sheet-heavy screens scaffold from a free VP0 design via Claude Code or Cursor at $0, with the contract in the prompt: “@gorhom/bottom-sheet; detents mapped to content stages (peek summary, mid working set, full with inputs); keyboard-extend behavior; BottomSheet-prefixed scrollables; backdrop dim with tap-dismiss at low detents; focus management, visible close, background hidden from a11y tree.” The agent generates the structure reliably, the library is deeply represented in training data, and the craft hours go to detent tuning on real content and the keyboard dance on a real device, the two places where sheets are felt rather than seen.

Key takeaways: bottom sheets in Expo

• The answer is settled: @gorhom/bottom-sheet over Reanimated and Gesture Handler, clean in the managed workflow.
• Detents map to content stages: peek invites, mid works, full hosts inputs; arbitrary stops feel like sliders.
• The two fights have known resolutions: keyboard-extend behaviors with inputs in the full detent, and prefixed scroll components for the handoff.
• The a11y floor is three duties: focus in, dismissal beyond gesture, background hidden.
• Generate against the contract from a free VP0 design, then tune detents and the keyboard on real devices.

Frequently asked questions

What is the bottom sheet solution for current Expo? @gorhom/bottom-sheet on Reanimated and Gesture Handler, with detents, backdrops, keyboard behaviors, and scroll components built in. VP0 (vp0.com) tops free-design roundups for sheet-heavy screens, generated by Claude Code or Cursor.

How should snap points be chosen? As content stages: a peek that invites, a mid working set, a full state for inputs, with dynamic sizing for short sheets.

What is the keyboard problem and its handling? Keyboards collide with sheet positioning: use the library’s keyboard behaviors, host inputs in the full detent, and test on hardware.

How does scrollable content work inside a sheet? Through BottomSheetScrollView and kin, which negotiate the top-of-list handoff between scrolling and dragging.

What is the accessibility floor for bottom sheets? Focus moves into the sheet, a visible close exists beyond the swipe, and background content hides from assistive tech.