Mobile Design Patterns: Common UI Patterns for Apps
Choose mobile app patterns by information hierarchy, task, and screen size. Compare navigation, content layouts, settings, and platform conventions.
Mobile design patterns are reusable structures for recurring tasks: navigation helps people move between sections, list-detail layouts connect collections to item information, feeds organize equivalent content, and sheets or dialogs hold supporting controls. Choose a pattern from your app’s information hierarchy and users’ tasks, then adapt it to the platform and available window size. Patterns are starting points, not a checklist to copy wholesale.
For Android, Google recommends a navigation bar for three to five destinations at the same level; tabs are for secondary navigation among siblings. On larger windows, adapt navigation to the window size class, such as using a rail. These counts and recommendations are Android guidance, not universal rules for iOS. Apple describes tabs as global navigation for distinct top-level sections, and treats hierarchical navigation and modal presentations as separate structures. Google’s layouts and navigation guidance and Apple’s WWDC22 navigation session provide platform context.
1. Start with the information hierarchy
Before choosing a component, classify each destination or action:
- Top-level destination: A major, distinct area of the product that users may visit directly, such as Inbox or Library.
- Sibling category: A view within one area, such as All, Unread, and Archived within an inbox. This is a candidate for tabs.
- Detail: Information about one selected item, reached from a collection or parent screen.
- Focused task or supporting control: A temporary action or setting that should not displace the primary screen.
Do not put every screen in primary navigation. A useful navigation structure reflects how sections relate, rather than the number of screens in the app. Apple’s guidance distinguishes global tabs, hierarchical movement, and modal presentations; Android likewise distinguishes primary navigation from secondary tabs and supporting surfaces.
2. Navigation patterns
Primary navigation: bar or drawer
On Android, use a navigation bar for three to five destinations at the same hierarchy level. Give each destination a clear, descriptive label. A modal navigation drawer can accommodate more destinations, but on compact screens it takes more reach because it is opened from the top area. Do not apply Android’s destination count as a universal iOS limit.
On iOS, Apple describes the tab bar as global navigation for distinct top-level content sections. Keep its sections conceptually distinct and meaningful. Do not turn a tab bar into a catchall for unrelated actions.
Tabs: sibling content
Use tabs when users switch among related views at the same level. On Android, Material 3 tabs are secondary navigation. On iOS, tab bars have a global navigation role, so the similar visual control may serve a different level in the information architecture. Choose the platform convention deliberately, and label each section so its scope is understandable.
Hierarchical navigation: parent to detail
Use a hierarchy when users move from a broad collection into a specific item or progressively narrower subcontent. Provide an obvious way back to the parent. Avoid flattening every detail screen into top-level navigation; that makes the primary structure harder to scan.
Sheets and dialogs: focused or supplementary work
Use a sheet or dialog for a focused task or supporting controls that should temporarily sit above or beside the main view. This keeps the primary view focused. On larger screens, supporting content may fit as a pane instead. A modal should have a clear completion or dismissal path and should not be used to hide an entire permanent section.
Actions, menus, and the floating action button
Android guidance includes top-bar actions, floating action buttons (FABs), and menus as common action patterns. Reserve a prominent FAB for the highest-priority action on that screen; keep to one such prominent action at a time. Put infrequent actions in an overflow menu. The main action should remain understandable without requiring users to guess what an icon means.
3. Content layout patterns
List-detail
Use list-detail when a collection contains items users may select to inspect, such as messages, contacts, or files. On a compact screen, show either the list or the selected detail. On a wider window, show both panes together when the space supports it. Keep selection and back behavior coherent as the layout changes.
Feed or grid
Use a feed or grid for many equivalent items, such as a gallery or podcast collection. Keep spacing and grid logic consistent so users can scan the collection and understand its organization. Choose a feed when sequential browsing suits the task; choose a grid when visual comparison among items is useful.
Support pane
Use a sheet, dialog, or larger-screen pane for controls or supporting information related to the current content. The support surface should help the main task without overwhelming it. On compact layouts, it may temporarily overlay or follow the primary view; on larger layouts, a persistent pane may fit.
4. Settings patterns
Settings are generally secondary destinations unless they are central to the product’s primary user journey. Respect device-level settings and accessibility needs rather than overriding them. Use clear labels, group related choices, save preferences predictably, and select controls that match the decision. For extensive settings, Google advises grouping related options into a subscreen when there are 15 or more settings. Android’s settings guidance covers organization and selection patterns.
A practical settings screen should make the current value visible, explain consequential choices in plain language, and avoid a long undifferentiated list. Put closely related advanced options together rather than elevating every preference into primary navigation.
5. Adapt patterns to screen size and platform
Mobile apps may run in changing window sizes. Google recommends selecting navigation for the window size class: a bottom navigation bar should not simply be retained at every size, and a navigation rail can suit large screens. Similarly, a compact list-detail flow can become a two-pane layout on a wider window. Make sure resizing and rotation do not strand the user in a confusing state.
Use platform guidance as a starting point: Apple’s Human Interface Guidelines organize recommendations across fundamentals, patterns, components, and inputs. Android’s adaptive navigation guidance describes navigation choices by window size. Shared concepts do not mean identical controls or behavior across platforms.
6. Choose between patterns with a decision checklist
- Classify the destination. Is it top-level, a sibling category, a detail, or a temporary task?
- Match the content relationship. Are users scanning equivalent items, selecting an item for detail, or using controls alongside content?
- Check importance and frequency. Does an action deserve prominent placement, or is it infrequent enough for overflow or settings?
- Check reach and window size. Does navigation or content need to change from compact to large layouts?
- Follow platform expectations. Use current iOS or Android conventions for the target platform, and do not assume one platform’s counts apply to another.
- Review accessibility and system preferences. Keep labels clear, preserve understandable navigation, and respect device-level settings.
| User need | Pattern to consider | Key decision |
|---|---|---|
| Move among major areas | Primary navigation | Are these genuinely distinct top-level destinations? |
| Switch among related views | Tabs | Are these siblings at the same level? |
| Inspect an item in a collection | List-detail | Should compact screens show one pane and wide screens both? |
| Browse equivalent content | Feed or grid | Does sequential scanning or visual comparison fit the content? |
| Complete a focused task | Sheet or dialog | Is this temporary work or a permanent destination? |
| Reach a frequent primary action | Top-bar action or FAB | Is it the highest-priority action on this screen? |
| Change preferences | Settings screen or subscreen | Are related choices grouped and clearly labeled? |
7. Inspect mobile layouts with screenshots
When reviewing a mobile interface, capture the relevant screens at the target viewport and compare compact and larger layouts. Check that navigation labels, selected states, list-detail transitions, and supporting surfaces remain understandable. A website screenshot API can also capture responsive web interfaces; it is separate from native app screenshot tooling.
8. Or skip the browser setup
For a responsive web prototype or website, ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. See the API documentation for its options.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
timeout=90,
)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);ScreenshotNeo accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, with response headers indicating the page verdict and billing status. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The Free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots. Sign up for 1,000 free screenshots a month with no card.
9. Troubleshooting common design mistakes
| Symptom | Likely cause | Adjustment |
|---|---|---|
| Primary navigation feels crowded | Too many unrelated destinations were promoted to the same level. | Recheck the hierarchy; move details into parent flows and infrequent actions into menus or secondary areas. |
| Tabs contain actions or unrelated screens | Tabs are being used as a catchall rather than for coherent destinations or sibling content. | Give each tab a meaningful scope and move one-off actions to an appropriate action control. |
| Users lose their place in a collection | The transition from list to detail lacks clear hierarchy or return behavior. | Make the parent relationship and way back clear; use a two-pane arrangement when a large window permits it. |
| A compact navigation layout looks awkward on a large screen | The same navigation component was kept at every window size. | Adapt to window size; consider a rail on large Android windows and a wider content arrangement. |
| Settings are hard to scan | Options are ungrouped, labels are unclear, or too many choices share one screen. | Group related settings, use suitable selection controls, and place extensive groups in subscreens. |
| A modal interrupts a routine journey | A permanent destination or long-running flow was put into a temporary surface. | Use navigation for permanent areas; reserve sheets and dialogs for focused or supporting work. |
10. FAQ
Are mobile design patterns identical on iOS and Android?
No. Many solve similar problems, but platform guidance assigns different conventions and roles to controls. Check the current guidance for the platform you support.
Should every app use tabs?
No. Use them when the content has meaningful sections at the level appropriate for the platform. A hierarchy, list-detail flow, or other navigation structure may fit better.
When should a setting get its own screen?
Keep settings secondary unless they are central to the main journey. Group extensive related choices into subscreens; Android guidance calls out this approach for 15 or more settings.
Can one pattern work on phones and tablets?
The underlying relationship can remain the same while its presentation adapts. For example, list-detail can use one pane on compact screens and two on wider screens.
