Mobile App Navigation Design: A Practical Guide

Mobile app navigation design should use a tab bar or Android navigation bar for 3–5 peer, top-level destinations, then place deeper screens one level below each destination so users reach them in two taps. Use a navigation drawer when the app has more than five top-level destinations. Size iOS tab bars at 49 pt before the bottom safe-area inset and Material 3 navigation bars at 80 dp. Keep frequent actions in the lower third of a 6.9-inch phone, provide 44 × 44 pt iOS and 48 × 48 dp Android touch targets, and preserve each platform’s native Back behaviour.

Key takeaways

• •Use a tab bar or Material 3 navigation bar for 3–5 peer destinations.
• •Use a navigation drawer when the app has more than five top-level destinations.
• •A standard iOS tab bar is 49 pt high before its bottom safe-area inset.
• •Material 3 navigation bars use an 80 dp container height.
• •iOS interactive controls need a 44 × 44 pt minimum target; Android targets need 48 × 48 dp.',

This guide is for mobile UI/UX designers, founders, and engineers who can map screens and flows but need to choose and specify cross-platform navigation.

Time: 35 minutes · You'll need: A complete screen inventory or information architecture map, A 6.9-inch phone artboard, such as iPhone 16 Pro Max at 440 × 956 pt, An iOS and Android component library, A prototype with Android gesture navigation enabled

What's on this page

1. •Group destinations by user intent
2. •Choose tab bar design for peer destinations
3. •Map bottom navigation mobile to thumb reach
4. •Set touch targets before styling icons
5. •Preserve platform back behaviour
6. •Reference table

• •Common mistakes
• •FAQs

Build mobile app navigation design step by step

1. Group destinations by user intent

List every screen, then mark whether it is a top-level destination, a child screen, a task step, or a transient overlay. A top-level destination has its own purpose and should retain its state when someone switches away and returns. For a fitness app, Today, Plan, Progress, and Profile are four peer destinations; Workout Detail belongs under Today or Plan, not beside them.

Count only peers in the top-level set. Choose tab bar design when that count is 3–5. Material Design 3 positions a navigation bar as the compact-screen pattern for three to five destinations. When the count exceeds five, use a navigation drawer rather than shrinking labels, adding a sixth tab, or hiding destinations behind an overflow menu. The drawer can hold lower-frequency top-level areas, settings, and account destinations.

For every top-level destination, draw its first child screen. If a user cannot reach a frequent destination in two taps from a peer destination, move that screen up one level or merge it with a related destination.

Tip: Do not promote Settings to a tab solely because it exists; reserve the 3–5 slots for destinations people visit during the app’s primary task.

2. Choose tab bar design for peer destinations

On iOS, use a bottom tab bar for persistent access to peer sections. Specify the bar as 49 pt high, then allow the system’s bottom safe-area inset to extend its background below that 49 pt content area on devices with a Home indicator. Keep each tab’s icon and label stable; changing the meaning or order by screen state breaks spatial memory.

On Android, use the Material 3 NavigationBar for the same compact-screen role. Its container height is 80 dp. Use text labels with the icons so that destinations remain identifiable without relying on glyph recognition. Give each destination a selected state, preserve its navigation state where the product expects it, and keep the current section visible after a user returns from a child screen.

Use no more than five items. A sixth item makes labels compete for horizontal space and turns a primary navigation control into a guessing exercise. If one section is clearly secondary, place it in the drawer or inside Profile instead.

Tip: A five-item bar is not automatically better than a four-item bar; leave a destination nested when it is usually entered from one parent section.

3. Map bottom navigation mobile to thumb reach

Create a reach overlay on a 6.9-inch iPhone 16 Pro Max artboard: 440 × 956 pt. Divide the 956 pt height into three working bands: the lower 0–320 pt is the easy one-handed zone, 320–640 pt is the stretch zone, and the upper 640–956 pt is outside comfortable one-handed reach for many right- or left-thumb holds. These bands are a layout test, not an Apple or Android system specification.

Put the tab bar, high-frequency destination switches, and the primary action for a feed or list in the lower band. The status area, top navigation title, search entry, overflow actions, and contextual filters sit in the upper band and require a stretch, a grip change, or a second hand. That trade-off is acceptable when those controls are not repeated during the main task.

Do not solve upper-screen reach by duplicating every action at the bottom. Duplicate only actions with high frequency and high task cost, such as adding an item during a grocery run or resuming a workout.

Tip: Test both left- and right-handed holds; a trailing top-corner action is especially costly for a right-handed one-thumb hold.

4. Set touch targets before styling icons

Draw the interactive hit area before drawing the icon. On iOS, make every tappable tab item, icon button, and custom control at least 44 × 44 pt. On Android, make each touch target at least 48 × 48 dp. The visible icon can be smaller when its invisible hit region meets the platform minimum and does not overlap another control.

Apply the rule to compact navigation rows as well as tab bars. A 24 pt icon placed in a 44 pt or 48 dp target is valid; two 24 pt icons separated by a 4 pt gap are not, because their effective hit regions become ambiguous. In a bottom bar, center each icon-label pair inside its own equal-width destination target.

Check the actual prototype rather than the artboard. Safe-area padding, gesture insets, and a device’s display scaling can expose targets that look generous in a static design but are difficult to hit at the bottom edge.

Tip: Keep the visual bounds and touch bounds aligned when possible; oversized invisible targets can make adjacent controls trigger unexpectedly.

5. Preserve platform back behaviour

Specify Back as a platform behaviour, not as one shared visual control. On Android with gesture navigation, the user invokes the system Back gesture from the left or right screen edge. Back should return to the prior screen or dismiss the current transient surface according to the system navigation history. Do not replace this with a custom top-left arrow that follows different rules.

On iOS, a pushed screen in a navigation stack commonly supports the leading-edge interactive pop gesture: swipe from the left edge to return to the previous screen. The navigation bar’s back button performs the same stack return. Do not make a tab tap behave like Back; switching tabs changes sections, while Back leaves a child screen or dismisses a presentation.

Write expected results for each state: detail screen, modal sheet, search mode, drawer, and root tab. At a root destination, Android Back should follow the app’s system-history expectations rather than cycling through tabs; iOS has no system-wide Back gesture equivalent that should be simulated inside the app.

Tip: Test Android predictive Back animations on every modal and custom navigation transition; a destination that cannot animate or return correctly has an incomplete Back contract.

Reference table

Cross-platform navigation measurements

Common mistakes

Putting six or more equal-priority destinations in a bottom bar.

Keep the bottom bar to 3–5 peer destinations. Move additional top-level destinations into a navigation drawer and retain their labels there.

Treating a tab switch as a Back action.

A tab switch changes top-level context. Android Back and the iOS edge swipe should return through navigation history or dismiss the current presentation.

Drawing 24 pt icons as 24 pt touch targets.

Use 44 × 44 pt hit regions on iOS and 48 × 48 dp hit regions on Android, even when the visible icon is smaller.

Placing repeated actions only in the top-right corner on a 6.9-inch phone.

The upper 316 pt of a 440 × 956 pt artboard is outside the comfortable one-thumb zone. Move high-frequency actions into the lower band or place them in a bottom sheet.

Frequently asked questions

How many tabs should a mobile app have?

A mobile app should have three to five tabs when those destinations are peer, top-level areas. Material Design 3 recommends a navigation bar for three to five destinations on compact screens. If the app has more than five top-level destinations, use a navigation drawer rather than adding a sixth tab or an unlabeled overflow tab.

What is the difference between a tab bar and a navigation drawer?

A tab bar exposes three to five frequent peer destinations at the bottom of the screen, while a navigation drawer holds a larger set of destinations behind a side panel. Use the tab bar when fast switching is part of the primary task. Use the drawer when the information architecture has more than five top-level areas or mixed-frequency destinations.

How tall should bottom navigation mobile be?

Use a 49 pt iOS tab bar before the bottom safe-area inset and an 80 dp Material 3 Android navigation bar. The iOS safe area extends the bar’s background and keeps controls clear of the Home indicator. Do not copy the 49 pt iOS measurement into Android layouts, because Material 3 uses a different component specification.

Should Android Back return to the previous tab?

Android Back should return through the user’s navigation history or dismiss the current transient surface, not cycle through previous tabs. A tab is a top-level destination rather than a sequential step. With gesture navigation enabled, users invoke system Back from the left or right edge, so the app must preserve a predictable destination history.

What touch target size should mobile navigation use?

Mobile navigation controls should provide at least 44 × 44 pt targets on iOS and 48 × 48 dp targets on Android. Those measurements apply to the tappable region, not necessarily the visible icon. A smaller icon is acceptable when it sits within a non-overlapping target of the required size.

Where this leaves you

The navigation pattern should reveal the app’s information architecture rather than compensate for an ungrouped screen list. Count peer destinations first: use a bottom tab pattern for three to five, and move a larger set into a drawer. Then verify the physical implementation: 49 pt plus the safe area on iOS, 80 dp on Android, and platform-sized hit targets. Make the lower 320 pt of a 6.9-inch test artboard carry the controls people repeat. Your next action is to label every existing screen as top-level, child, task step, or transient surface, then redraw the resulting two-tap paths.

---

Design the screens first

Describe the screen you need in plain English and floow.design generates production-ready iOS and Android layouts you can iterate on by chat, then export to Figma or code. Design your mobile app screens in floow.design first, then build.

Start designing free →

---

Related

• •Color Picker from Image — Pull a palette out of any image, assign it to screen roles, and export it as tokens or native code.
• •Aspect Ratio Calculator — Work out the missing width or height for any ratio, with the common phone and store ratios one click away.
• •User Persona Generator: Write App Personas — Use a user persona generator or a manual worksheet to create two testable mobile app perso
• •User Flow Diagram Generator: Mobile App Guide — Build a user flow diagram generator-ready map for one mobile task: four node types, failur
• •UI Design Prompts: 25 That Generate Usable Mobile Screens — Learn a practical formula plus 25 UI design prompts that create editable, usable mobile sc

Sources

• •Apple Human Interface Guidelines — Tab bars
• •Apple Human Interface Guidelines — Buttons
• •Material Design 3 — Navigation bar
• •Material Design 3 — Navigation drawer
• •Android Developers — Touch target size