A practical guide to picking the main navigation pattern for a mobile app, with a decision rule for tab bars, drawers and gestures, and the mistakes to avoid.
Tab Bar, Drawer or Gestures: Choosing Mobile App Navigation
Most navigation problems in mobile apps are not caused by a bad pattern. They are caused by choosing a pattern before counting what the app actually contains. A tab bar fails when you have nine destinations. A drawer fails when your users need to reach three destinations every minute. Gestures fail when nothing on screen tells people they exist.
This post gives you a way to choose. It covers the three patterns you will meet most often, a decision rule, and the mistakes we see most in early designs.
Start by listing destinations, not screens
A destination is a place a user goes on purpose and comes back to. "Home", "Orders", "Profile" are destinations. "Order detail" and "Edit address" are screens inside a destination.
Write the list on paper before you open a design tool. For each destination, add two notes:
- How often a typical user visits it (every session, weekly, rarely)
- Whether the user needs to jump to it from anywhere in the app
The answers decide the pattern. Frequent and global destinations belong where the thumb can reach them without a second tap. Rare ones can hide.
The tab bar
A bottom tab bar shows your top-level destinations all the time, one tap away. Both Apple's Human Interface Guidelines and Google's Material guidance describe it as the default for apps with a small set of equally important destinations.
Use it when:
- You have between three and five top-level destinations
- Users switch between them often
- Each destination is roughly equal in weight
Watch out for:
- A fifth or sixth item. Material's bottom navigation guidance recommends three to five destinations, and iOS compresses extra tabs into a "More" tab that hides them. If you need six, you probably have two destinations that should merge, or one that belongs in a menu.
- Labels that are icons only. Icons without text are guesses. Keep short text labels under every icon.
- Using the tab bar for actions. "Create" can sit in the middle of a tab bar, but it is an action, not a place. If it opens a sheet and not a screen, consider a floating button instead.
- Resetting state. When someone taps away from a tab and back, they expect to find the tab as they left it. Tapping the active tab again should scroll to top or return to the root of that tab.
The navigation drawer
A drawer slides in from the side and holds a longer list of destinations. It saves screen space and scales to many items. It also hides everything by default, and hidden things get used less.
Use it when:
- You have more than five destinations and cannot merge them
- Most destinations are secondary (settings, help, account switching, legal)
- Users spend long stretches in one main view, such as a mail client or a file manager
Watch out for:
- Putting primary destinations in it. If users need Orders every day, do not make them open a menu first.
- The hamburger icon on its own, as the only way to move around. It is easy to miss and requires reaching to a top corner, which is the hardest area to reach one-handed on a large phone.
- Deep nesting. A drawer with expandable sections inside expandable sections is a file tree. Cap it at one level.
A common and sound combination: a tab bar for the three or four frequent destinations, and a drawer or a "Profile" screen for everything else. You get reach for the frequent items and room for the long tail.
Gesture navigation
Gestures include swipe back, swipe between tabs, pull to refresh, swipe on a list row to reveal actions, and long press for a menu. Modern iOS and Android both use system gestures for back and home, so your app already lives with them.
Gestures are good at speed and bad at discovery. Use them to accelerate something that already has a visible path, not to replace the path.
Good uses:
- Swipe back from the left edge (the system provides it; do not fight it)
- Pull to refresh on a feed
- Swipe a row to archive or delete, if a visible button or menu does the same thing
- Swiping between sibling views, such as days in a calendar
Bad uses:
- A gesture as the only way to reach a feature
- Custom edge swipes that collide with the system back gesture
- Gestures that destroy data without a confirmation or an undo
The rule: every gesture needs a visible twin. If someone cannot swipe (motor impairment, a switch device, a screen reader), they must still reach the feature through a button or a menu item.
A decision rule
Run this in order and stop at the first match.
- Three to five frequent, equal destinations? Tab bar.
- Many destinations, one dominant main view? Drawer, plus a clear title bar so people know where they are.
- Three to five frequent destinations plus a long tail? Tab bar for the frequent ones, drawer or profile screen for the tail.
- Content is a sequence the user moves through (onboarding, a wizard, a story)? Linear navigation with a visible progress indicator and a back button. Gestures can add swiping, but buttons stay.
- Anything else? Your information architecture is probably not settled. Go back to the destination list.
Mistakes and fixes
Mistake: choosing by screenshot. A team likes another app's navigation and copies it, but that app has different content and different frequency of use. Fix: build your destination list first and compare it to what the reference app actually contains.
Mistake: different navigation on iOS and Android with no reason. Platform conventions matter, such as the system back behavior on Android and the swipe-back on iOS, but your top-level structure should be the same on both. Fix: keep the same destinations, adapt only the platform-specific behavior.
Mistake: hiding the current location. Users should always be able to answer "where am I?" Fix: highlight the active tab or drawer item, and give every screen a clear title.
Mistake: forgetting the thumb. On a tall phone, the top corners are the least reachable zone. Fix: put frequent controls near the bottom, and treat the top-left hamburger as a secondary entry point.
A five-minute test
Before you build, make a clickable prototype with only the navigation shell and placeholder screens. Give five people tasks such as "find your last order" or "change your notification settings". Do not explain the navigation. Watch for:
- Hesitation before the first tap
- Tapping the wrong tab first
- Opening the drawer and then closing it without choosing anything
Three of five people hesitating at the same spot is a signal. Fix the labels or the grouping, then test again.
FAQ
Can I use a tab bar and a drawer together? Yes. Keep the tab bar for the frequent destinations and use the drawer for settings, help and account items. Avoid putting the same item in both.
Should the tab bar hide when the user scrolls? It can, to give content more room, but it must come back on scroll up. If the app's whole job is moving between tabs, leave it fixed.
Do gestures work for accessibility? Only when a visible alternative exists. Test with a screen reader on and off before you ship.
Talk to us
If you are planning a mobile app and the navigation is still unsettled, we are happy to look at your destination list and sketches. Write to hello@risingstation.com or use risingstation.com/contact-us.
Md Kabir Hossain
Co-Founder & CTO
