The Bottom Sheet Problem: Why Your Modal Feels Like It's Fighting the User

You tap a button in your app, and instead of a smooth panel sliding up from the bottom, a jarring full-screen modal slams into view, blocking everything, with a tiny "X" in the corner that's easy to miss and impossible to reach with one thumb. Multiply that friction across every filter, every share sheet, every "edit profile" action, and you've got an app that feels like it's actively working against the person using it. This is the bottom sheet problem, and it's one of the most common ways indie apps signal "built by an engineer, not designed for a human" — something Dolfy.ai was built specifically to help solo founders and developers avoid. Bottom sheets are the modal panels that slide up from the bottom edge of the screen (think a share menu, a filter panel, or a comment box), and getting them wrong costs you more than aesthetics — it costs you completed tasks.

Key Takeaways

• Bottom sheets should cover 40-90% of the screen height depending on content, never a jarring full-screen takeover for a two-field form.
• A visible drag handle (a small horizontal bar, roughly 36-40px wide) signals "this is draggable" without a single word of instruction.
• Dismissal needs three redundant paths: swipe down, tap the scrim (the dimmed background overlay), and an explicit close action — losing any one frustrates a chunk of users.
• Sheets should be built from design tokens (reusable values like corner-radius-lg or spacing-16) so every sheet in your app shares the same rounded corners, padding, and animation timing automatically.
• On iOS the system leans toward spring physics for the slide-up animation; on Android, respecting Material's motion duration (roughly 300ms) keeps things feeling native rather than web-wrapped.

Why do bottom sheets feel more natural than full-screen modals?

Bottom sheets feel natural because they preserve context — the user can still see a sliver of what they were doing underneath, which tells their brain "this is temporary, I haven't left where I was." A full-screen modal, by contrast, reads as a hard context switch, like being yanked into a different app. That's fine for a genuinely separate flow (onboarding, a full-screen photo editor), but it's overkill for "pick a delivery time" or "leave a comment." Apple's Human Interface Guidelines and Google's Material Design both converged on the bottom sheet pattern for exactly this reason: it's a lighter-weight interruption. When you're prototyping in a tool like Figma or Sketch, it's tempting to reuse one full-screen modal component for everything because it's the easiest artboard to duplicate — but that shortcut becomes a real cost once it's shipped as actual React Native or Flutter code, because now every "quick action" in your app carries the same heavy, disorienting transition.

How tall should a bottom sheet actually be?

The height should match the content, not an arbitrary default — a rule of thumb is roughly 40% of screen height for a short form (a single input, a couple of toggles) and up to 90% for something closer to a full task (writing a review, configuring notification preferences). The mistake most solo-built apps make is picking one fixed height and cramming everything into it, which either leaves a form floating awkwardly in a half-empty sheet or forces users to scroll inside a cramped box while the rest of the screen sits unused above it. Some platforms support snap points — multiple resting heights the sheet can settle into as the user drags it, like a "peek" state at 25% and a "full" state at 90%. That's a nice-to-have, not a requirement: even a single well-chosen height beats a modal that ignores its own content. This is part of why Dolfy's Design OS methodology asks you to define your data model and content shape for a screen before touching layout — if you know a "quick reply" sheet only ever holds 80 characters of text, you can size it correctly from the start instead of guessing.

What makes a bottom sheet feel dismissible?

Three things, and skipping any one of them creates a dead end for some segment of your users: a swipe-down gesture on the sheet itself, a tap anywhere on the dimmed scrim behind it, and a visible close control for people who don't know (or can't perform) the gesture. Roughly a third of users on any given screen won't discover an undocumented swipe gesture on their own — accessibility research on discoverability consistently finds a meaningful chunk of users rely on explicit, labeled controls rather than gestures. If your bottom sheet only closes via swipe, you've built a trap for exactly those users. The visible drag handle mentioned earlier does double duty here: it's both an affordance (a visual hint about how something works) that signals "swipeable" and a component that itself defines the touch target for the gesture, so your team isn't reinventing that trade-off with every new sheet you add.

Why does the same sheet look different across screens in my app?

Because it was probably built by hand, three or four separate times, with three or four slightly different corner radii, padding values, and animation curves — a symptom of skipping design tokens rather than a one-off bug. A design token is a named, reusable value (like radius-modal: 20 or duration-sheet: 280ms) that every component pulls from instead of hardcoding its own number. Without tokens, a developer implementing the "share" sheet on a Tuesday and the "filter" sheet on a Thursday will eyeball slightly different values, and the drift compounds over a few sprints into an app where nothing quite matches. This is the exact handoff gap that breaks a lot of solo-built apps: a design system (a shared set of rules, tokens, and components documented in one place) that lives only in someone's head, or in a Figma file nobody re-opens, degrades the moment a second screen needs the "same" component. Dolfy's approach is to generate the token system and the production-ready TypeScript component code together in its Design Foundation and Export steps, so the bottom sheet component you preview in Expo Go is the exact component — same radius, same spacing, same timing — that ships.

Does the sheet need to feel different on iOS versus Android?

A little, yes — not in structure, but in motion and physics, because ignoring platform conventions is one of the fastest ways to make a cross-platform app feel like neither app it's imitating. iOS users are used to a springy, slightly bouncy slide-up (UIKit's default sheet presentation uses spring damping), while Android's Material Design spec calls for a more linear, roughly 300ms standard-easing transition. React Native and Expo apps that just apply one animation curve everywhere tend to feel "close enough" on one platform and subtly wrong on the other — not broken, just a little uncanny, in a way most users can't name but definitely notice. The fix isn't building two separate components; it's parameterizing the animation timing and easing curve as platform-aware tokens within a single shared component, which is a small amount of extra setup that pays for itself the first time you add a fifth or sixth sheet to the app.

What should I check before shipping a bottom sheet to production?

Before shipping, confirm the sheet has all three dismissal paths, that its height was chosen based on actual content rather than convenience, that it pulls its corner radius, padding, and animation timing from your shared tokens rather than local hardcoded values, and that you've tested it with a keyboard open (a shockingly common miss — a text input inside a bottom sheet needs the sheet to resize or reposition when the keyboard appears, or the input gets hidden entirely). Running through that checklist on even 3-4 of your most-used sheets before launch catches the majority of the complaints that would otherwise show up in App Store reviews weeks later.

Frequently Asked Questions

Are bottom sheets better than full-screen modals for every use case?

No — full-screen modals are still the right call for genuinely separate flows like onboarding, a photo/video editor, or checkout, where the user is meant to feel like they've left the current context. Bottom sheets are for quick, contained actions where staying connected to the underlying screen matters.

What's a reasonable bottom sheet height if I only have time to pick one?

If you can only support a single fixed height, 60-65% of screen height is a safe middle ground for most quick-action content (a form with 2-4 fields, a short list of options) — tall enough to avoid internal scrolling for typical content, short enough to keep the screen behind it visible and legible.

Do I need a design tool like Figma before I can build a good bottom sheet?

Not necessarily — the discipline that matters is defining the content and data first, then the layout, then locking the visual details into reusable tokens. Dolfy's Design OS methodology is built for developers who want to skip the separate Figma file entirely and go straight from a defined data model to production-ready React Native and Tailwind CSS components.

How much engineering time does a properly tokenized bottom sheet component actually save?

Teams that build one token-driven sheet component instead of one-off implementations typically cut the time to add a new sheet-based feature from a day or more of layout tweaking down to under an hour, since the corner radius, spacing, and animation are already solved and just need new content dropped in.

Building Sheets That Feel Like Part of the App, Not a Patch on It

The gap between "a modal that technically works" and "a bottom sheet that feels native" comes down to a handful of specific, checkable decisions — height tied to content, three dismissal paths, tokens instead of hardcoded values, and platform-aware motion. None of it requires a design background, but it does require making those decisions deliberately instead of defaulting to whatever a UI library ships out of the box. If you're building your app's screens from scratch and want that consistency baked in from the first component rather than patched in after launch, Dolfy walks you through defining your data model and design tokens before generating the production React Native and TypeScript components — so your bottom sheets, and everything else in the app, come out looking like they were designed as one system instead of assembled from a dozen different tutorials.