Mobile Interaction Patterns
The conventions phones have settled on, what each one is actually for, and where they break.
Definition
Mobile patterns are the structures people already know from the platform: tab bars, sheets, swipe actions, pull to refresh. Their value is recognition, so deviating from them costs more here than on the web.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this page
Patterns and their conditions
| Pattern | Use when | Breaks when |
|---|---|---|
| Bottom tab bar | Three to five top-level destinations of equal standing | It carries sub-navigation, or the count grows past five. |
| Bottom sheet | A focused task that keeps the context visible behind it | It stacks, or it holds a form longer than the visible area. |
| Swipe actions on a row | A frequent action on a list item | It is the only route to the action, or the affordance is invisible. |
| Pull to refresh | A feed whose freshness matters | The content updates automatically anyway, or the list is not the top scroll region. |
| Long press | Secondary actions for experienced users | It hides something people need on their first day. |
The physical constraints
- Reach: the top corners of a large phone are hard to hit one-handed, so primary actions belong low.
- Target size: at least 44 by 44 points on iOS, 48 by 48 density-independent pixels on Android, with spacing between adjacent targets.
- Safe areas: the notch, the status bar and the home indicator all overlap content that ignores them.
- Interruption: mobile sessions are short and interrupted, so state must survive backgrounding.
- Connectivity: the network is worse than your office. Design the offline and slow paths deliberately.
Adapting from desktop
Do
- Give every gesture a visible equivalent.
- Replace wide tables with a per-record layout rather than a horizontally scrolling grid.
- Use the platform's own controls for dates, selection and sharing.
- Keep the primary action reachable with a thumb.
Do not
- Do not stack a desktop layout and call it responsive.
- Do not disable zoom, or set a font size that triggers automatic zoom on focus.
- Do not put destructive actions where a swipe can reach them by accident.
- Do not block system gestures with your own.
In practice
Table to list on a phone
A twelve-column table cannot be read on a 375 pixel screen. Showing the two identifying columns plus the one the reader sorted by, with the rest on a detail view, keeps the task possible without a horizontal scrollbar.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
Human Interface Guidelines
Apple
Source of the 44 point target minimum and of platform gesture conventions.
Material Design Guidelines
Google
Source of the 48 dp target minimum and of bottom navigation limits.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Principles behind this
The reasoning this solution is an application of.
- Fitts's LawLaw
- Adaptive LayoutUI foundation
- Responsive LayoutUI foundation
Often used with
These usually appear in the same screen or the same decision.
- Drawer and SheetComponent
- NavigationPattern
Practical example
A worked decision where this was the deciding factor.
- Putting a Data Table on a PhoneCase study