In March 2016, Google added Bottom Navigation to its design guidelines. This release was quite surprising to many, as Bottom Navigation hadn’t been mentioned in previous Material Design iterations. Bottom tab bars were common in iOS apps, while older Android guidance discouraged them. These were design recommendations, not platform limitations or a requirement for every iOS app.
This is the first article in a series on Android Bottom Navigation, covering its usage and historical evolution.
Version note (reviewed 2026-10-13): The images and Do/Don’t guidance below belong to historical Material Design 1 (M1), not a complete specification for Material 3 (M3). The official change log records bottom navigation in March 2016. Section 6 adds current implementation guidance. Material design versions are not Android OS versions.
1. Previous Android Bottom Bar Design Specs
2. WeChat’s Redesign
WeChat’s navigation redesign caused a stir before Google’s official guidance. The original article associated it with version 5.2. The two historical screenshots below show different tab placements, but do not establish exact releases, test scope, or how quickly a change was reversed.
3. Google+’s Redesign
Google+ was another prominent example discussed at the time. Google announced its redesign on November 17, 2015; the original screenshot is retained below:
Well, so much for that rule. WeChat hadn’t followed it and seemed to be doing a lot better than Google+ anyway.
4. Bottom Navigation Design Specs
Enough gossip; let’s look at the official Bottom Navigation Design Guidelines. Most of us programmers aren’t as good at design as the designers. Some guidelines can at least help us avoid making something too ugly.
4.1. Usage
M1 bottom navigation primarily targeted mobile layouts; side navigation was an alternative on larger displays. This is an in-app component, distinct from Android’s system Back/Home buttons or gesture-navigation area.
4.1.1. When to Use
Use Bottom Navigation when:
- There are three to five top-level destinations of equal importance.
- These destinations need frequent, direct access.
This does not require a visible bottom bar on every login, editing, or full-screen task. M1 itself excluded focused tasks such as composing an email.
[Do and Don’t] 1. Number of Items
M1 suggested considering tabs below three destinations. Choose by content hierarchy, not count alone: two categories within one content area may fit tabs, while independent top-level destinations need a broader navigation decision.
[Do and Don’t] 2. No Horizontal Scrolling
The M1 page mentions alternative access above six destinations in one paragraph, but explicitly limits the bar to five elsewhere. Six is not an endorsed bar size. Regroup additional destinations or provide another entry, such as a drawer, instead of scrolling the bar horizontally.
[Do and Don’t] 3. Optimal Item Count
Keep three to five primary destinations; excessive items compromise tap targets as well as appearance. These M1 illustrations are historical examples, not current M3 color or label templates.
5. Bottom Navigation vs. Tabs
Bottom navigation and tabs can coexist when their hierarchy is clear. For example, a bar can switch between Home, Favorites, and Profile, while tabs inside Favorites group related content. Avoid having both controls compete for the same pages or silently change the bar’s destinations.
Tabs support tapping; swipeable pages require an additional implementation such as a pager. Swiping is not an automatic feature of a Tab or the defining distinction between the controls. See the current Compose tabs guide.
6. 2026 Update: Implementation Choices
- Components. Use M3 NavigationBar / NavigationBarItem in Compose, or Material Components BottomNavigationView in View projects. Three to five consistent top-level destinations of similar importance remain the recommendation. Keep M2/M3 imports distinct; library versions are not OS API levels.
- Windows. Adapt to the app’s current window, not a device or orientation label.
NavigationSuiteScaffoldbelongs tomaterial3-adaptive-navigation-suite. From 1.0.0-alpha07, its version line moved to Material3 1.3.0, released September 4, 2024; consult the release notes for project compatibility. The current adaptive guide describes a default bar for compact width or height, or tabletop posture, and a rail otherwise. A drawer requires customization, not merely a tablet device. - State. Displaying a selected item does not manage the back stack. Keep selection aligned with the actual destination and decide how each flow resumes. Jetpack Navigation 2.4.0 added multiple-back-stack support. The relevant View
setupWithNavController()integration differs from configuring Compose navigation. Saving an index withrememberSaveableis not a substitute for stack management.
Continue with Part 2: Style and interaction, again distinguishing historical M1 illustrations from modern components.
About Me && Blog
Below is my personal intro and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”
- Blogger Intro
- Blog Content Navigation: A guide for my blog content.
- Curated Excellent Blog Articles - Android Performance Optimization Must-Knows
- Android Performance Optimization Knowledge Planet: The paid community stopped operating in 2026 and no longer accepts new members; this link preserves its history.
One walks faster alone, but a group walks further together.
