By Mehdi HassanWhich mobile navigation pattern should your app use?
Your app should use a bottom tab bar if it has three to five top-level sections that people switch between often. That covers most consumer and B2B mobile apps. Apps that do one job well are better served by a single main screen with sheets and a few pushed screens, and apps with many sections need a tab bar for the core and a menu or profile screen for the rest.
The pattern follows from your information architecture, so write that down first: list every destination, then mark how often a typical user visits each one. The frequent ones earn persistent navigation. The rare ones can live one tap deeper. This sorting exercise is part of the wider process in our mobile app design guide, and it settles most navigation debates before anyone opens Figma.
App type | Recommended pattern | Why |
|---|---|---|
Social, content, marketplace | Bottom tab bar (4–5 tabs) | Frequent switching between feed, search, create and profile |
Banking and fintech | Tab bar plus a prominent primary action | A few core areas, one dominant task such as pay or transfer |
Single-job utility (scanner, timer, calculator) | Single screen with sheets | There's nothing to switch between |
AI assistant or chat-first app | Single conversation screen plus a history list | The conversation is the product |
Field or workflow tool (B2B) | Tab bar for core tasks, list-detail inside each | Repeated tasks, often one-handed and on the move |
Content-heavy reference or docs | Search-first with a browse menu | Too many sections for tabs; people know what they want |
Tablet or foldable layouts | Navigation rail or sidebar | More width; bottom bars stretch poorly |
How does the thumb zone affect mobile navigation patterns?
The thumb zone is the area of the screen a person can reach comfortably with the thumb of the hand holding the phone. On a modern phone held one-handed, that's the lower and middle part of the screen; the top corners need a stretch or a second hand. Navigation and frequent actions belong where thumbs reach easily.
Screen area | Reach (one-handed) | Best used for |
|---|---|---|
Bottom third | Easy | Tab bar, primary action, main input field |
Middle | Comfortable | Content, list rows, cards, secondary actions |
Top third | Stretch | Titles, status, back, search entry, rarely used controls |
Top corner opposite the hand | Hard | Nothing the user needs often |
This is why bottom navigation replaced top tabs and side drawers in most apps, and why both Apple and Google now put navigation bars at the bottom of phone layouts. It's also why a hamburger icon in the top-left corner is doubly costly: it hides the destinations and puts the button in the hardest place to tap. Pull-down search and bottom sheets are popular for the same reason.
Tab bar vs hamburger menu: which is better?
A tab bar is better for core navigation because it shows every main destination all the time, tells users where they are, and puts switching one tap away in the easiest place to reach. A hamburger menu saves space by hiding destinations, and hidden destinations get used less because people forget they exist.
Pros
- Hamburger: fits many destinations without crowding
- Hamburger: keeps the screen clean for content-first apps
- Hamburger: works well for settings, help, legal and account pages
Cons
- Hamburger: hides core features behind an extra tap
- Hamburger: gives no sense of where you are in the app
- Hamburger: usually sits in the top corner, the hardest place to reach
The best apps use both. The tab bar carries three to five core sections; a profile or More tab, or a menu inside it, holds everything else. If you're tempted to add a sixth tab, that's a sign to merge two sections or move one into a secondary screen, not to switch to a drawer. Nielsen Norman Group has published research on hidden navigation that is a useful starting point if you need to make this case to a team.
When does gesture navigation work on mobile?
Gesture navigation works when it speeds up an action people already know how to do another way. Swipe to go back, swipe a list row to archive, pull to refresh and swipe between adjacent tabs or photos are all established. Each has a visible alternative, so the gesture is a shortcut, not the only route.
Gestures fail when they're the only way to reach a feature. Nobody discovers a hidden swipe from an empty area of the screen, and custom gestures can also collide with system ones: swiping from the left edge goes back on iOS, and both edges trigger back on Android. Keep custom horizontal gestures away from screen edges, and test them with system gesture navigation turned on. We cover the platform differences in iOS vs Android design.
How should navigation work inside each section?
Inside each section, navigation should move in one direction: from a list to a detail screen and back, with modal sheets for focused tasks. Each tab keeps its own stack, so switching tabs and coming back returns the user to where they were, not to the top.
- Push a new screen when the user drills into something (a list item, a setting).
- Present a sheet for a self-contained task: create, filter, edit, confirm. Closing it returns to exactly where they were.
- Use full-screen modals sparingly, for flows that need full attention such as a checkout or a camera.
- Keep the tab bar visible on pushed screens unless the screen needs every pixel, such as a media viewer.
- Make destructive or money-moving actions explicit, with a clear confirmation state. The DeFi app UX guide covers this for transaction flows.
For example, suppose you're choosing navigation for a fitness booking app
For example, suppose a fitness studio app has these destinations: class schedule, my bookings, memberships, studio locations, trainer profiles, payment methods, notifications, account settings and help.
Ranked by frequency, schedule and bookings are daily; memberships and locations are weekly at best; the rest are rare. A good structure is a three-tab bar (Schedule, Bookings, Profile), with locations and trainers reachable from class details, and memberships, payments, notifications, settings and help inside Profile. Booking a class opens a sheet, so the user never loses their place in the schedule.
This is a hypothetical walkthrough, but the method, ranking destinations by frequency before picking a pattern, applies to any app.
What about web apps and larger screens?
On tablets, foldables and desktop web apps, navigation moves to the side: a navigation rail for a handful of sections, or a full sidebar for products with many areas. The bottom bar that works on a phone looks stretched and sparse on a wide screen, and side navigation makes use of the extra width.
If your product has both a mobile app and a web app, keep the same sections and names across both, even though the pattern changes. Users switching devices should find Bookings in the same place conceptually, whether it's a tab or a sidebar item. For desktop product patterns, see our web app UI design guide, and for conversation-first products, AI chat interface design covers how history and threads fit in.
