Mobile UI Patterns skill for Claude Code

A mobile screen is done when a user can reach its primary action with one thumb, get back to where they came from with the platform’s own back gesture, never lose their place when switching tabs, and nothing important sits under the notch, the home indicator or the keyboard — on the smallest supported phone at the largest text size.

Scope

This skill owns pattern selection and screen-level specification. Framework code lives in swiftui-views, jetpack-compose, flutter-widgets and react-native-expo; VoiceOver/TalkBack and Dynamic Type implementation in mobile-accessibility; app structure and sitemaps in information-architecture; layout for responsive web in responsive-layouts.

Step 0 — establish platform targets

Before designing, confirm: iOS, Android, or both; native or cross-platform (SwiftUI, Compose, React Native/Expo, Flutter, mobile web/PWA); minimum OS versions; tablet and foldable support. iOS 26 (Liquid Glass) and Material 3 Expressive changed navigation chrome; check which design generation the app already follows and stay consistent.

The “website in a wrapper” look, and what to do instead

Tell	Native-feeling choice
Hamburger menu holding primary destinations	Bottom tab bar (iOS) / navigation bar (Android) with 3–5 destinations
Custom back arrow that ignores swipe-back	Platform navigation stack; system back gesture always works
Centered modal dialogs for every task	Sheets for short tasks, full-screen modals for multi-step creation, alerts only for decisions
Primary button at the top right of long forms	Primary action reachable at the bottom (pinned above the keyboard or safe area)
32px tap targets and hover-dependent controls	44×44pt (iOS) / 48×48dp (Android) minimum, 8dp spacing
Toasts covering the status bar	Snackbar at the bottom above navigation (Android); inline confirmation or a brief banner below the nav bar (iOS)
Heavy drop shadows on every card	Flat grouped lists and platform materials; elevation only where layering is real

Navigation model

Situation	Pattern
3–5 top-level destinations used frequently	Tab bar (iOS) / navigation bar (Android), each tab with its own stack
2 destinations	Segmented control or top tabs within one screen, not a tab bar
6+ destinations	Re-group in IA first; a “More”/profile tab for low-frequency items; Android modal drawer only on phones when unavoidable
Drill-down through hierarchy	Push onto the current tab’s stack with a titled back affordance
Self-contained task (compose, create, filter, edit)	Modal: sheet if short, full-screen if multi-step; explicit Cancel/Done
Tablet / foldable / large window	iPad sidebar or tab bar that adapts to sidebar; Android navigation rail (expanded rail replaces the drawer in M3 Expressive)
Linear flow (checkout, onboarding)	Stack with progress; back goes to the previous step, not out of the flow

Tab rules:

• Each tab preserves its own navigation stack and scroll position when switching.
• Tapping the active tab pops to its root; tapping again at root scrolls to top.
• Never hide the tab bar on drill-down unless the screen is immersive (media, camera).
• Labels always visible under icons; icons alone are ambiguous.
• iOS 26: tab bars float on Liquid Glass, may minimize on scroll, and support a dedicated search tab at the trailing end. Use the system tab bar to get this for free instead of rebuilding it; a custom opaque bar will look dated next to system apps.
• Material 3 Expressive replaces the original navigation bar with a shorter flexible navigation bar and favors the navigation rail on medium and larger windows. Use the current Material components rather than hand-sizing bars.

Sheets and modals

Need	Use
Quick choice or a few fields, context should stay visible	Sheet at medium detent (iOS) / modal bottom sheet (Android)
Persistent secondary panel (map + list, player)	Non-modal sheet with detents / standard bottom sheet
Multi-step or long form	Full-screen modal with Cancel (leading) and Done/Save (trailing)
Irreversible decision	Alert / dialog with a specific verb (“Delete 3 photos”) and Cancel
Choose among actions on an item	Action sheet (iOS) / bottom sheet menu (Android); destructive item marked

Rules: sheets have a visible grabber and close by swipe-down, tapping outside (modal sheets only) and a close button for accessibility. If a sheet has unsaved input, confirm before dismissing on swipe. Never stack a sheet on a sheet on a sheet — two levels maximum.

Back navigation and gestures

• iOS: the left-edge swipe-back must work on every pushed screen. Custom navigation bars that break it are the most common native-feel failure.
• Android: support predictive back — handle back through the platform’s back callback APIs (OnBackPressedCallback, Compose BackHandler/PredictiveBackHandler) rather than intercepting key events, so the system preview animation works on recent Android versions.
• Every gesture needs a visible alternative: swipe-to-delete also offers a menu or edit mode; pull-to-refresh also refreshes on screen focus or via a button for accessibility.
• Do not attach custom gestures to screen edges; they conflict with system back and home gestures.
• Swipe actions: at most 2 per side, destructive on the trailing side with confirmation or undo.

Thumb zones and layout

• Primary actions in the bottom third; the top corners are the hardest reach on large phones. Put rarely used or destructive actions there, not the main CTA.
• Keep destructive actions physically separated from the primary action.
• Android: floating action button for the single most frequent creation action (bottom-right); M3 Expressive also offers FAB menus and floating toolbars for a small set of related actions. iOS: a ”+” in the navigation bar or a bottom toolbar button.
• Content width: single column; 16pt/dp side margins as the default; 20pt on larger iPhones is common in system apps.
• Lists over cards for homogeneous data; grouped/inset lists for settings.

Safe areas and edge-to-edge

• Respect safe areas for notch, Dynamic Island, status bar, home indicator and gesture navigation bar. Backgrounds extend edge to edge; interactive content stays inside.
• Android 15+ enforces edge-to-edge for apps targeting SDK 35 or higher: apply window insets (WindowInsets in Compose, ViewCompat.setOnApplyWindowInsetsListener in Views) or content will draw under the system bars.
• Mobile web: <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">, pad fixed bars with env(safe-area-inset-bottom), use 100dvh instead of 100vh.

Keyboards and forms

• Set the right keyboard per field: email, number pad, phone, URL, one-time code (textContentType = .oneTimeCode / autocomplete="one-time-code").
• Return key advances to the next field and submits on the last (“Next”, “Go”, “Done”).
• Keep the focused field and the submit button visible above the keyboard; scroll or pin the action bar to the keyboard.
• Support autofill for names, addresses, passwords and passkeys; never block paste.
• One column, labels above fields, at least 16px text on mobile web to stop iOS zoom-on-focus.
• Use native pickers for dates and times unless the domain needs a custom one (booking calendars).

Cross-platform decisions

Element	Adapt per platform	Share across platforms
Navigation chrome, back behavior, tab bar style	Yes	—
Alerts, action sheets, date/time pickers, switches	Yes (native components)	—
Typography	System font per platform (SF Pro / Roboto) or one brand face	Brand face if part of identity
Content layouts, illustrations, brand color, iconography style	—	Yes
Haptics	Platform APIs and conventions	Same moments (success, error, selection)

React Native/Expo and Flutter: use navigation libraries that render native stacks (@react-navigation/native-stack, Expo Router; Flutter’s Cupertino and Material widgets per platform or adaptive constructors) so back gestures and transitions match.

Workflow

- [ ] 1. Platform targets and design generation (Step 0)
- [ ] 2. Top-level destinations from the IA; choose navigation model
- [ ] 3. For each flow: push vs sheet vs full-screen modal
- [ ] 4. Place primary actions in reach; check destructive separation
- [ ] 5. Specify gestures with visible alternatives; back behavior per screen
- [ ] 6. Safe areas, keyboard handling, field types
- [ ] 7. Platform-adaptive vs shared decisions documented
- [ ] 8. Verify on devices at smallest size and largest text

Verification

1. Run on the smallest supported phones (for example 375×667pt iPhone SE class and a 360dp-wide Android) and the largest; nothing clipped, nothing under system bars.
2. Set the largest accessibility text size; layouts reflow, nothing truncates critical information.
3. One-handed test on a large phone: complete the top 3 tasks holding the phone in one hand; note any reach for the top corners.
4. Back test: swipe-back on iOS and predictive back on Android from every screen in each flow returns to the expected place; tab stacks are preserved.
5. Keyboard test: every form completes without dismissing the keyboard manually to reach the submit button.
6. Quick VoiceOver/TalkBack pass on the main flow; full audit via mobile-accessibility.

Gotchas

• A tab bar that resets each tab’s stack on switch — users lose their place.
• Full-screen modals without a Cancel, relying on swipe-down that users do not discover.
• Using a sheet for a flow that later grows to five steps; promote it to full-screen.
• Floating action buttons on iOS and hamburger drawers on iOS — both read as ports.
• Custom transitions that ignore Reduce Motion.
• Designing in Figma at 390pt wide only; real devices include small phones, split-screen iPad and foldables.

Output when reporting

**Navigation:** tab bar (Home, Search[iOS search tab], Library, Profile); stacks per tab
**Modals:** New playlist = medium sheet; Edit profile = full-screen with Cancel/Save
**Back:** native stacks; predictive back via BackHandler on Android
**Reach:** primary CTAs pinned bottom above safe area; delete moved to overflow
**Platform split:** pickers, alerts, nav chrome native; content layouts shared
**Verified:** SE + Pixel 360dp, largest text, one-handed top-3 tasks, back from every screen