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?

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.

Tabs on Twitter’s iOS App

The Tab Bar on Trello’s iOS App

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

In addition, Tabs often have icons or numbers indicating that there’s new content available for the user

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.

An example of the More tab in Apple’s Music App

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.

Tabs on Twitter’s Android App

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

Android apps (like Backdrops) typically let users swipe the screen horizontally to navigate between Tabs.

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.

If applicable, the top of a Navigation Drawer typically shows user specific information.

The bottom of a Navigation Drawer can show secondary sections.

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)

Twitter’s iOS app’s Navigation Bar

Twitter’s iOS app’s Navigation Bar with a back button

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

button on the left if there’s a screen to navigate back to A Navigation Drawer button if there is no Up button

button Menu buttons and overflow menu with more options

Note that on Android apps with both a Toolbar and Tabs, the two are merged into a single element.

The overflow menu on Youtube’s Android App

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

On iOS the only way for the user to navigate back is through a back/close button on the left side of Navigation Bar.

Android

Since Android has an onscreen navigation bar, the design documentation distinguishes between The Up Button and the Back Button.

The Up Button

The Up button is typically included in a toolbar and moves the user back to the last screen that they viewed in your app (until they reach the app’s home screen).

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.