Developing for Android vs. iOS: Navigation Patterns
In last week’s article, we started with a high level approach where we described the differences between the Design Languages of iOS and Android: Flat Design and Material Design, respectively.
If you don’t have a good understanding of Flat vs Material yet, then I recommend you read up on that before reading this article.
Over the next few weeks, we’ll be going over more Native vs. Hybrid mobile development and other differences between the Android vs. iOS platforms.
This week, let’s talk about Navigation Design Patterns.
When you’re thinking about how your users are going to navigate your mobile app, you should be asking yourself the following kind of questions:
- How should the user navigate though the difference sections of my app?
- Should I use a Navigation Drawer or Tabs?
- Should my tabs be on the top or the bottom of the screen?
- How do I let my user go back from their current view?
We’ll be answering these questions for both the iOS and Android platform (with case studies from some very popular apps). If you haven’t already, and would like to receive an update when these next articles are posted, please subscribe to our mailing list (no spam, I promise). If you’re an entrepreneur/ developer in the mobile space and are planning to release your mobile app on both iOS and Android, it’s imperative that you understand the specifics of each ecosystems and user base to ship better software.
Why bother studying Navigation?
Navigation is one of (if not the) most important part of a mobile app. Since mobile device screens are pretty small compared to laptops, you typically can’t show everything your app can do in a single screen. Thus, it’s vital to explain to the user how to navigate from one section to another. Making smarter user experience decisions (and recording how users react to them) can greatly change how users utilize (or abandon) your app.
Tabs
When your app has a couple of main sections and you want to let your user quickly switch between them, Tabs are a solid choice. Tabs let you organize the main views of your app and let users quickly explore the content in each of them.
iOS
On iOS, Tabs are at the bottom of the screen. It is a very well known and familiar navigation design approach that’s used by a lot of successful products such as Facebook, Twitter, and Instagram. iOS tabs typically have both an icon and text.
A typical usage of Tabs has each one encompassing a section of your application:
- Home (main content) Tab
- Search (if there’s content to search) Tab
- Compose/Create Tab
- Notifications Tab
- Profile Tab
There’s a convention and limitation on having up to 5 tabs. Conventionally there shouldn’t be more than 5 “big” things your application does (this is just a good UX experience in general).
In portrait mode there’s only so much space horizontally on iOS devices. Thus if you put a 6th tab there would be no room for all of them and the system would “flop” them into a More Tab. Tapping on that dotted tab opens a list of other tab options that didn’t make it into the Tab bar.
Android
On Android, Tabs are at the top and are typically represented as either text or icons (rather than text and icons), unless you’re going for a bottom navigation bar, see below.
Android Tabs are typically more focused on app specific sections than iOS and less so on “secondary” sections like Search, Create/ Compose and Profile as Android has other navigation elements to fulfill those roles.
Swiping
Bottom Navigation Bar
The bottom navigation bar is a relatively new Android design pattern which tries to mimic how tabs are used in iOS. While I personally argue that a bottom tab is silly in Android (since it’s too close to Android’s iconic Navigation Bar), Google says the following on Tabs vs. Bottom Navigation:
Tabs make it easy to explore and switch between different views and
Bottom Navigation bars make it easy to explore and switch between top-level views in a single tap.
Side Navigation Drawer
If your app has more than a handful of main sections (or “secondary” sections like settings and feedback), a Navigation Drawer is another very popular design pattern. It allows you to provide the user with a list of sections that they can tuck away when they don’t require it.
iOS
On iOS, Navigation Drawers are not a native design pattern. They came to the platform as iOS design evolved but are still an important part of navigation in a lot of applications.
Since Apple does not provide an API to implement Navigation Drawers, developers typically use third party libraries (here’s a partial list).
Android
On Android, Navigation Drawers are a native design pattern, so Google provides you with the APIs you need to build a navigation drawer, no need to search for a third party APIs.
Top Bars
iOS
On iOS the top bar is called the Navigation Bar. Navigation Bars typically include:
- The title of the section the user is currently on
- A back button on the left if there’s a screen to navigate back to
- A content control element on the right if applicable (like Search)
The Navigation Bar’s main purpose is to allow the user to navigation through a series of hierarchical app screens via usage of the back button.
Android
On Android the top bar is called the Toolbar. Android’s Toolbar is more standardized than iOS and typically includes:
- The title of the section the user is currently on
- An Up button on the left if there’s a screen to navigate back to
- A Navigation Drawer button if there is no Up button
- Menu buttons and overflow menu with more options
The menu buttons and overflow menu can be used as an both alternative and a supplement to a Side Navigation Drawer. An overflow menu can potentially remove the need for a Side Navigation Drawer depending on how many different views your app needs to contain.
Alternatively, you can let each section from your Side Navigation Drawer have it’s own overflow menu with further options that your user can interact with.
Back Buttons (and Android’s Navigation Bar)
It’s great to navigate to a screen, but it’s also important to make it obvious to users how to go back.
iOS
Android
Since Android has an onscreen navigation bar, the design documentation distinguishes between The Up Button and the Back Button.
The Up Button
The Android Navigation Bar and Back button
The back button is part of the Navigation Bar and “navigates in reverse chronological order through the history of recently viewed screens”. While the Up button won’t take users out of your app, the Back button can take the user from the current app to the one they were previously using.
One significant difference between iOS and Android is how the prior has a physical home button (that also serves as a thumb print scanner), and the latter forgoes a front facing physical button to have a bigger screen (and throws the thumb print scanner on the back of the phone).
Even if it’s a “system” design pattern rather than an “app” one, Android’s Navigation Bar can be hidden and immersive media apps (such as Youtube, Google Photos, Netflix, ect) will hide the Navigation Bar to let the user focus on the content the app is presenting.
Since the Navigation Bar includes a back button, it’s not uncommon to see Android apps not include an Up Button and have the user utilize the Back Button since their functionality is very similar.
Conclusion
That’s it for this week’s article on Navigation Patterns on iOS and Android.
In the next article, we’ll be going over Native vs. Hybrid development for mobile apps.
If you want to receive an update when these next articles are live, please subscribe to our mailing list. If you’re an entrepreneur/ developer in the mobile space and plan to target both Android and iOS, you’ll massively increase your chances of success if you understand the design and feature differences between these two operating systems and user’s expectations.
This article was co-authored by:
Jordan Rejaud, a Software Engineering Consultant who helps clients in the mobile space by architecting and writing the software they need.
and
Alex Bush, a Software Engineer at SmartCloud. He blogs about advanced iOS topics and Ruby on Rails.
