Mobile App Design Patterns That Work

When Steven Hoober watched people using phones in public, roughly half held the phone in one hand and worked it with that thumb. Phones get used on the move and in between other things. Most of the patterns that have survived in mobile app design survived because they cope with those conditions, and the ones that faded assumed a seated user with two free hands and full attention.

Bottom navigation for the main destinations

A bar of three to five tabs along the bottom edge is the default for apps with a handful of top-level areas. Google's Material Design puts the range at three to five destinations, and Apple's Human Interface Guidelines cap an iPhone tab bar at five, moving anything beyond that into a More tab.

It works because it sits where the thumb already is. Switching tabs should also preserve each tab's state: if someone scrolled halfway down a feed, went to their profile and came back, they expect the feed where they left it. Resetting it to the top makes every tab switch cost the user their place.

Teams break the pattern by overloading it. A sixth tab gets squeezed in, labels shrink to icons only, or one tab turns into a launcher for an unrelated feature. If a destination needs explaining, it belongs one level down.

The hamburger menu still has a place for long lists of secondary destinations like settings, help and legal pages. For primary sections it hides the options users need most, and people are less likely to find sections they can't see.

Where thumbs reach

On today's tall screens, the top corners are the hardest spots for a one-handed thumb to reach.

So the most frequent actions should sit in the lower half: primary buttons, the tab bar, a floating compose button. Rare or destructive actions can live higher up, where a stray tap is less likely. Apps that put search or "new" in the top-right corner force a grip change every time someone uses them.

Touch targets need to be large enough for a finger. Apple recommends at least 44 × 44 points; Material recommends 48 × 48 density-independent pixels. WCAG 2.2 sets a lower floor of 24 × 24 CSS pixels for its AA target-size criterion. The visible icon can be smaller than the target, as long as the tappable area around it meets the size and doesn't overlap a neighbour's.

Bottom sheets for secondary tasks

A bottom sheet slides up from the bottom edge and holds content related to the screen underneath: share options, filters, the details of a map pin. It keeps the user in place, which matters when the underlying screen is the thing they're working on.

Sheets come in two kinds. A modal sheet blocks the screen behind it and needs to be dismissed. A non-modal one, like the panel in a maps app, sits alongside the main content and can be dragged between heights. Both should close with a downward swipe, and a modal sheet should also close when the user taps the dimmed area behind it.

Sheets become a problem when they stack. A sheet that opens a second sheet, which opens a dialog, leaves the user unsure how many layers they're under. When a task needs more than one step, use a full screen with a back button.

Gestures need a visible alternative

Swipe to delete, pull to refresh and long-press menus save time for people who know them. Nobody learns them by looking at the screen, though. A gesture with no visible cue is a shortcut, and every action it triggers should also be reachable through a button or menu.

Two conflicts come up again and again. Horizontal swipes inside the app can collide with the back swipe from the left edge on iOS and the system back gesture on Android. And custom gestures on a scrolling list compete with the scroll itself, so a user trying to scroll ends up archiving a message. Keep custom gestures away from screen edges, and test them with people who haven't been told they exist.

Loading, empty and offline states

Mobile connections drop in lifts and tunnels. An app that only has a design for "data loaded" will show users a spinner far more often than its designers expect.

For content that takes more than a moment to arrive, skeleton screens (grey placeholders in the shape of the coming layout) show that something is happening and where it will appear. For actions like liking a post or ticking a task, optimistic updates reflect the change immediately and reconcile with the server afterwards, rolling back with a message if the request fails.

Empty states deserve the same attention. A new user's inbox, a search with no results and a list the user has cleared are three different situations. The first needs a way to get started, the second needs help adjusting the query, and the third can simply confirm there's nothing left.

Offline, the app should show what it has cached, mark it as possibly out of date, and queue changes to send later where that's safe. Blocking the whole screen with a "No connection" message throws away content the phone already has.

Asking for permissions

Both platforms show a system dialog the first time an app asks for location, contacts, the camera or notifications (on Android, notifications only in recent versions). On iOS, a user who declines can only turn the permission back on in Settings. On Android, the app can ask again, but after repeated denials the system stops showing the dialog.

That makes timing important. Asking for notifications on the first launch, before the user has seen anything worth being notified about, gets a lot of refusals. Asking at the moment the permission becomes useful, for example requesting location when the user taps "find stores near me", gives the request an obvious reason.

A short screen before the system dialog that explains what the permission is for can help, as long as it doesn't imitate the system dialog or make "not now" hard to find. If the user declines, the feature that needed the permission should say what it can't do and link to settings, instead of failing silently.

Forms that fit a phone keyboard

Typing on glass is slow and error-prone, so the best mobile form is a shorter one. Remove fields that can be inferred or asked later. Use the right keyboard for each input: numeric for card numbers and one-time codes, email for email addresses, telephone for phone numbers. Set the autocomplete attributes so the system can fill addresses, passwords and one-time codes from a text message.

Keep the label visible above the field, not inside it as placeholder text that disappears on the first keystroke. Validate when the user leaves a field, not on every character, and put the error message next to the field it belongs to. Make sure the keyboard doesn't cover the field being edited or the submit button.

Sign-in is where these rules matter most, because it's often the first form a user fills in. Passkeys, magic links and sign-in error messages are covered in login page design patterns.

Onboarding that shows the product

Many apps open with three or four swipeable slides describing features. Most users skip through them without reading, and the ones who do read have forgotten the content by the time they need it.

Let people reach the core of the app quickly and teach features in context: a one-line hint the first time someone opens the editor, a sample project already loaded so the screen isn't empty. Where an app needs information from the user before it's useful, such as a fitness app asking for goals, keep the questions few and explain how the answers change what they'll see.

Account creation can wait. Letting someone try the product before asking them to sign up, and saving their work when they do, removes a barrier at the point where they have the least reason to push through it.

Respecting platform conventions

iOS and Android differ in navigation (Android has a system back action; iOS relies on in-app back buttons and the edge swipe), in date pickers, in share sheets, in typography and in the look of switches and alerts. A cross-platform app doesn't need to look like two separate products. It should, though, behave the way each platform's users expect for things the system owns: back navigation, sharing, text selection, notifications and system font sizes.

Dynamic Type on iOS and font scaling on Android let users enlarge text system-wide. Layouts built with fixed heights and truncated labels break when someone does, and the people who enlarge text are often the ones who most need the app to work. Test every screen at the largest text size before shipping.

Screen sizes vary too, from small phones to foldables and tablets running the same app. The principles in our responsive design guide apply to native layouts as much as to the web.

Where to look for mobile app design inspiration

Pattern galleries and screenshot libraries are useful for seeing how different apps handle the same screen, such as a checkout, a settings page or an empty inbox. They show the layout but not whether the pattern tested well.

App-by-app breakdowns live under mobile interfaces. The principles behind these patterns sit in the interaction design hub, with menus and wayfinding covered under navigation design.

Frequently asked questions

What are mobile UI patterns?

They are reusable solutions to problems that come up repeatedly in phone interfaces: how to move between sections, how to show secondary options, how to handle loading and errors. Tab bars, bottom sheets, pull to refresh and skeleton screens are all patterns. Using established ones means users arrive already knowing how the screen works.

How many items should a mobile tab bar have?

Three to five is the common range, and five is the iPhone ceiling. With two, a segmented control or a single screen is simpler. Beyond five, the labels get too cramped to read and some destinations should move to a secondary menu.

What size should touch targets be?

At least 44 × 44 points on iOS and 48 × 48 dp on Android. WCAG's 24-pixel minimum is a compliance floor, and fingers need more room than that.

Should a mobile app copy its website's design?

It should share the brand, content and terminology so users recognise it, but the layout and navigation should follow mobile conventions. A website's top navigation bar and hover states don't translate to a thumb on a small screen.

How do you test mobile app design?

Test on real devices, held in the hand, including an older and smaller phone than the team uses. Run usability sessions with tasks people actually do in the app, try the app on a slow or unreliable connection, and check every screen with the largest system text size and a screen reader turned on.

If your app's core flows haven't been checked on a small phone with one hand and a weak signal, that is what a Full UX Audit → does.