Bottom sheet or full screen? Choose the right mobile surface

Keep short object actions beside their object

Activations puts favorite, download, playlist, share and information actions in a sheet while the audio title remains partly visible behind it. Othership groups a similar set of session actions, adding facilitator information and session details. In both cases, the menu belongs to an existing session rather than introducing a new product area.

That relationship is the strongest reason to choose a sheet. The user has already selected the object; the remaining question is what to do with it. Make the object identifiable through a title, thumbnail or stable background. An ambiguous overflow button followed by an anonymous menu forces people to remember which row they opened.

Keep the first menu focused on immediate actions. If an option begins a long configuration flow, move into an appropriately sized destination instead of accumulating several layers of sheets. On return, restore the same object and list position. A sheet should shorten a local decision, not become a substitute navigation system.

Name the action scope before choosing a container

Cozi makes a different scope visible: its grocery menu contains Check all, Uncheck all and Delete checked. Those verbs act on a collection, not one grocery item. Atoms labels its menu Habit actions and offers edit, snooze, reflection, archive-like completion and delete choices for a habit. Similar containers therefore carry different consequences.

Decide whether each command applies to the current object, the checked subset, or the entire collection. The container cannot communicate that by itself. A bulk command needs a readable selection count and a clear scope. A single-object command needs the object identity. Do not use a generic Delete label where the person might reasonably expect only the selected row to disappear.

Model scope in the action payload before polishing the menu. Pass explicit object identifiers or a stable selection snapshot, not a mutable screen index. If content refreshes while the menu is open, do not quietly retarget the command to another row. Close the stale menu or explain that the object changed. This matters equally for a sheet and a full-screen action page.

Give very small decisions a very small surface

GoatChat presents Camera and Gallery in a Select Attachment action sheet with a Cancel option. The person is choosing a source, not completing an upload form. Behance exposes more project actions and separates a Cancel control from the action card; its destructive Delete command uses red text. The contrast is useful because a menu can remain local without making every option equally consequential.

A two-option source choice rarely needs the navigation overhead of a dedicated page. Follow the choice with the appropriate camera or picker, and return cancellation to the composer with its text intact. Do not confuse cancelling the source choice with deleting a previously attached image. The visible Cancel control should have one predictable effect.

For a consequential action, distinguish selecting the command from confirming the consequence. Color helps identify destructive intent but does not replace specific wording. If deleting a published project affects other people, a short confirmation can describe that consequence after the menu. Avoid confirmation dialogs for every harmless menu option; repeated warnings teach users to tap through the important one.

Move to a full screen when the task becomes a workspace

Snipd places playback speed, skip intervals and headphone actions in a Player settings view with section headings. Promeo dedicates a Text to Image screen to a prompt, aspect ratio and style selection. These are not merely menus of commands. The person is configuring several related values and may need to revisit them while understanding the combined result.

Use a full screen when a task requires reading, typing, inspecting a preview or comparing several groups of settings. A software keyboard can consume much of a short sheet. If important controls disappear underneath it, expanding the sheet is not automatically enough; the form still needs a coherent scroll and focus order. A dedicated screen often provides a clearer home for the work.

The practical threshold is not a fixed number of fields. Ask whether the person needs to move between controls, whether changes are reversible, and whether the task survives leaving the app. Define a draft for substantial input. Keep the output action available without covering the final field, and make the back action describe whether the configuration is retained or discarded.

Do not let contextual overlays turn into a maze

Uptime uses a sheet for actions on a particular content summary, including saving, downloading and reporting. ChatBoost exposes an image-creation workspace containing an optional photo, styles, ratio and prompt. Both have a local purpose, but only the first is a short action menu. Treating both as the same kind of overlay would ignore the amount of state the second asks people to maintain.

Document the complete path: entry trigger, surface, next destination, dismissal and return. A report action may open a form; an attachment source may open a system picker; a generation button may begin a long-running job. At every boundary, specify which surface is still active. Back should remove the most recent layer, not jump unpredictably to the library.

Keep one task owner responsible for the current draft. Nested surfaces can edit that draft, but they should not each create an independent copy with different save behavior. Test the shortest route and the abandoned route. A person who chooses a style, opens a photo picker, cancels it and returns should still find the same prompt and selected ratio.

Specify dismissal as a state transition

Write down the states before building the component: closed, open with unchanged values, open with changes, submitting, failed and complete. Dismissal from an unchanged menu can return immediately. Dismissal from an edited task needs a deliberate policy: preserve the draft, discard with confirmation, or save explicitly. Do not let the component library accidentally decide your product contract.

A modal surface should move focus into the task, keep background controls out of the active focus order, and return focus to the entry control when it closes. Give the close control an accessible name that describes its effect. Keep a visible alternative to gestures. A drag handle indicates a possible gesture, but it is not an adequate sole exit for someone using assistive input.

Treat gesture dismissal, platform back, keyboard escape and the visible close button as entries into the same dismissal policy. Test a submitting state separately: if closing does not cancel the operation, tell the user where the result will appear. Avoid changing sheets into full screens mid-task without preserving scroll, focus and the same draft identifier.

Test the abandoned path, not just the happy path

Give participants object-level tasks without naming the container: download this session, change the forward skip interval, or create an image with a portrait ratio. Observe whether they can identify the object, find the command, complete the task and return. Repeated reopenings often reveal a hidden control or unclear save rule rather than a need for a different visual style.

Instrument entry, action selection, successful completion, dismissal with changes, draft restoration and errors. Separate voluntary cancellations from failed completion. A lower dismissal rate is not automatically better if people cannot escape a task. Review accidental destructive actions and lost drafts alongside completion time.

Use small screens, large text, a visible keyboard and interrupted network requests in testing. The best surface is the one that preserves the task under those conditions. The recorded screens illustrate different choices, but your decision should follow your own input complexity, consequences and observed user behavior.

A surface-choice review you can use in a design critique

Use these checks on a working build, not only on the polished reference state.

• ✓Can the person name the object and the scope of every action before choosing it?
• ✓Does a short decision stay short, while sustained editing has enough room?
• ✓Is there a visible, accessible exit in addition to a gesture?
• ✓Do all dismissal routes preserve or discard the same state intentionally?
• ✓Does the keyboard leave the active field and primary action usable?
• ✓Are the original object, list position and draft restored on return?
• ✓Can an in-progress operation be found again after its surface closes?

Connect surface choice to the surrounding task

For settings that span several groups, compare the mobile app settings examples before deciding which controls belong in a local overlay.

If a sheet collects input rather than only actions, the mobile app signup-flow review helps examine focus, validation and preserved values. For file selection, compare how an entry surface leads into a picker.

The existing bottom-sheet reference gallery is the place to browse more containers. This article addresses the decision to use them, not a replacement gallery.