Mobile App UI in Figma: Frame Presets, Safe Areas, and a Practical Layout Workflow

Quick answer

Start every mobile screen from a device frame preset (or a team template frame) that already includes logical width, status bar, and home indicator placeholders, then draw your primary content inside a safe-area rectangle that respects notches, curved corners, and gesture zones. Use auto layout for rows that must stretch with dynamic type, pin fixed chrome to top and bottom, and export at 1× logical dimensions unless engineering asks for asset buckets at @2×/@3×. If you are new to responsive structure in Figma, read Figma Auto Layout in practice next; for shipping bitmaps and vectors, align naming with how to export production-ready assets from Figma.

Prerequisites

• A target minimum OS and device class (for example “iOS 17, iPhone 15 width” or “Material 3, compact phone”) documented in your file cover page.
• Shared color and type variables so dynamic type experiments do not fork one-off styles; variables and modes pair well with mobile theming.
• Agreement with engineering on whether designs are pt-based logical frames or physical px references—pick one and label the file.

Choose frame presets deliberately

iOS-oriented presets

Common community and first-party presets include status bar height, dynamic island or notch cutout, and home indicator margin. When you duplicate a preset:

• Rename the root frame with breakpoint + state (phone / home / default) so dev links stay stable.
• Lock the device chrome layer group so day-to-day edits do not nudge the status bar by accident.
• Keep marketing hero art in a separate bleed group if it intentionally runs under the status bar; primary tap targets and body copy still belong in the safe inset.

Android-oriented presets

Android density classes multiply quickly; most product teams standardize on 360×800 style logical frames for “phone compact” and add a tablet preset when navigation changes materially. Material guidance evolves—treat presets as starting geometry, not law, and confirm gesture navigation inset expectations with your Android engineer.

When to skip literal device frames

Marketing landing pages inside apps, modal sheets, and tablet master-detail layouts sometimes work better in neutral frames with annotated insets (“top safe 59”) than in decorative device bezels. Pick literal chrome when stakeholders need realistic screenshots; pick neutral frames when speed and component QA matter more.

Safe areas: what to draw and what to trust

Define a single “content” frame

Inside the device root, create a rectangle (or auto-layout frame) named safe / content that sits inset from edges by your team’s agreed minimum touch margin plus OS safe padding. All primary text, lists, and primary buttons should default to this region.

Handle split layouts

For bottom tab bars, either:

• Extend the bar to the physical bottom with proper home-indicator padding inside the bar component, or
• Float the bar above the indicator with a shadow—document which pattern engineering implements.

For toolbars under notches, mirror the same rule: never balance a critical icon solely in the curved corner “dead” zone.

Landscape and split-screen

If your app supports landscape, duplicate presets early—safe areas swap emphasis (notch on the side, reduced vertical height). Sketch at least one landscape frame per critical flow so prototyping does not invent impossible layouts later.

Grids and spacing that scale on phones

Baseline grid

An 8 pt vertical rhythm with 4 pt half-steps for tight chip rows remains the most common mobile default. Document exceptions (dense data tables) in your system README, not per screen ad hoc.

Column count

4 columns suit marketing-heavy scroll pages; 6 columns help dense settings screens. The goal is not pixel-perfect parity with code—it’s predictable snapping so engineers can map to flex gaps.

Type ramp

Pair grids with a type ramp that lists default / large accessibility sizes. When users bump dynamic type, auto layout should allow wrapping and vertical growth instead of overlapping clipped text.

Auto layout patterns that survive real devices

Scroll regions

Use a vertical auto-layout stack for header + scroll body + footer. Fix the header and footer to the top and bottom of the root frame; let the middle region use fill height with clip content so long lists behave predictably in prototype scroll wrappers.

Bottom sheets and keyboards

Create keyboard open variants that increase bottom inset by a documented keyboard height placeholder. Even if the number is approximate, the variant prevents “designs that only work with the keyboard hidden.”

Cards and lists

For swipe rows, duplicate list items as components with trailing actions revealed in a separate variant rather than drawing one-off masks—developers map variants to state machines more cleanly.

Status bar, notches, and color contrast

Treat the status bar region as real UI, not wallpaper:

• If you use light content on dark photography behind the status bar, test contrast the same way you would for body copy—our accessibility plugin roundup lists tools that help when stacks get busy.
• When switching light/dark mode, verify status bar style (light vs dark icons) against both brand backgrounds and scroll-under states.

Preview on device without leaving the file

Figma’s mobile viewers and Mirror-style previews are not pixel-perfect simulators, but they are excellent order-of-magnitude checks: tap targets feel smaller in the hand than on a 27” display, and scroll + sticky header interactions expose z-index mistakes early. Schedule a 10-minute device pass before milestone reviews—not every edit—and capture one annotated screenshot when you change safe-area assumptions. If your team already prototypes flows, reuse the same linked frame from how to use Figma to create a prototype so product and engineering critique the same geometry.

Component coverage checklist (phones)

• Navigation: tab bar, modal stack, and system back affordances (Android) vs swipe-from-edge behaviors (iOS)—draw the happy path plus one error / offline state.
• Keyboard: email, password, numeric, and search variants alter vertical space differently; include at least one secure field variant if you ship auth.
• Loading and empty: skeleton height should match final content height to avoid layout jumps that auto layout masks until prototype.
• Large accessibility sizes: one stressed variant per critical template proves your minimum touch targets still hold when labels wrap to two lines.

Handoff notes that mobile engineers actually read

Add a small annotation frame off-canvas per feature with:

• Minimum OS and device class tested.
• Safe-area source (preset name + manual inset tweaks).
• Scroll behavior (nested scroll vs single scroll parent).
• Asset scale expectations for icons and illustrations—cross-link icons and illustration plugins when designers rely on libraries for raster cut points.

Common mistakes

• Designing only at @3× then letting exports shrink without coordinated filenames—see the scale discussion in production exports.
• Mixing Android and iOS chrome in the same component set without platform variants—fork components at the navigation layer, not every chip.
• Ignoring dynamic type until QA: auto layout upfront saves reflow fire drills.
• Hard-coding notch math per screen instead of using a shared safe-area component—the next device generation breaks siloed values first.

FAQ

Should I use Figma’s device frames or a community kit?

Use whatever your team standardizes—consistency beats novelty. Community kits are fine when maintenance is assigned (someone updates presets after Apple or Google template changes).

How do I preview safe areas without a physical device?

Rely on preset guides + prototype scroll; add temporary red inset outlines during review, then hide them in the default layer style before dev handoff.

Do tablets deserve separate files?

Separate pages at minimum; separate files when release cadence or libraries differ. Navigation patterns diverge enough that shared phone components often sprawl if forced into one library.

Where do mobile patterns fit in the broader JustFigma library?

Browse Figma guides for setup and workflow context, and tutorials when you want step-by-step onboarding beside mobile-specific work.

Next steps

Save your preset page as a team template, wire variables for light/dark, then stress-test three screens: feed, form, and modal—those catch most safe-area and keyboard failures. When the layout is stable, move on to developer handoff plugins for spec clarity and token alignment.