top of page

Component wrap-up: App bars

App bars appear at the top of every app screen

Apple calls them Navigation Bars. Google calls them Top App Bars. Depending on who you talk to, you may also hear them called Title Bars, Top Bars, or Toolbars. No matter what you call them, this bar is an essential part of any app’s “chrome” — the elements that frame every screen in your app. Even if you create an incredibly minimal app, you’ll always have an app bar.

But why? What does an app bar do?

In essence an app bar provides a consistent space for app information, navigation, and sometimes even search. It answers two important questions for users: "Where am I?" and "What can I do here?"

Pretty important stuff, right? So it's worth getting to know your humble (and not so humble) app bar.

 

The nitty gritty of app bars

As you’d expect for a fundamental part of every app, there are existing UX guidelines available from both Apple and Google. And while there are differences this is one instance where they're outweighed by similarities.

Apple vs Google app bars

Similar structures

For starters, both iOS and Android app bars have nearly identical structures. Moving from left to right you see the same elements:

  1. Navigation: A menu icon or arrow for navigating back a screen.

  2. Title: The name of your app or the name of the current screen.

  3. Action and overflow icons: Icons for global or screen-specific options, like Search or Edit.

Google and Apple app bars share an identical structure

Each of the elements is optional, but what’s interesting is that even if you omit all of them, you still have an app bar — it’s just super minimal.

When would you omit elements? Well if your app is simple and has few (or no) additional screens, or if all your navigation is handled by something like tabs at the bottom of the screen, then you may not need navigation elements in your app bar.

Why might you skip a title? While a title helps users identify your app or which screen they’re on, sometimes that just isn’t necessary. For example the app Headspace uses brand colours and background imagery to establish its identity on the Home screen, so there’s no need to put “Headspace” or “Home” in the app bar — they'd just be redundant. Since one of the app’s design principles is minimalism the decision to eliminate extra elements was very appropriate.

The Headspace app bar is entirely free of elements

That leaves action and overflow icons. Apple recommends limiting your actions to a single control to avoid “crowding” the app bar. This hints at why you might or might not include actions in your app bar. If you want a clean, uncluttered, simple aesthetic then less is more and you want to minimize or eliminate app bar actions. On the other hand if you have a feature rich, complex app where your users need a lot of functionality without hunting for it, then you may need more actions in your app bar.

Choosing between large and small

Both Apple and Google support two versions of app bars — a normal height bar and a larger bar. For iOS these are called “standard” and “large”; for Android these are “regular” and “prominent.” The smaller versions are considered the default. Apple suggests using large when you need to “provide extra emphasis on context,” meaning you need your title to help users understand what they’re looking at. Google suggests using its prominent app bar for longer titles, which is nicely practical. They also recommend the prominent style for app bars that include background imagery — think branding.

Large or prominent app bars give the title more prominence

A fairly common practice is to use a large, customized app bar on the Home screen but the regular size on subsequent screens.

Note that going large does not give you more real estate for navigation or actions.

Compressing and hiding the app bar

So there are similarities in the look and structure of Apple and Google app bars, but what about interaction?

If you choose a larger app bar for your app, both Apple and Google recommend compressing it to the regular, smaller version when users scroll down. This creates more space for the content your user is viewing. In addition to this, Google suggests hiding the app bar entirely when the user continues to scroll. Apple doesn’t cover this in their Human Interface Guidelines but a quick peek at Safari shows this behaviour, which feels like implicit permission to follow suit.

Safari's app bar disappears and reappears when scrolling

Apple also recommends hiding the app bar when switching to full-screen content, like an image preview.

Special-purpose app bars

There are at least two special-purpose app bars you're likely to run across in popular apps. Google supports a "contextual action bar," and apps on both platforms often use a search bar. Both of these replace the regular app bar in specific situations.

Google's “contextual action bar” appears when the user selects something on the screen. This replacement bar indicates the number of selected items and any available actions for the selection. In essence this bar temporarily creates more real estate for actions.

Google's contextual action bar can temporarily replace the app bar

The search bar repurposes the real estate normally used by your regular app bar, replacing it with a search field and any related action icons. Using the app bar for the search field frees up the rest of the screen for search results.

The search bar replaces the app bar

Customizing the look and feel

Both Apple and Google support customizing the app bar with coloured backgrounds, background images, and your own fonts. These can help you reinforce your brand identity or add flair to your app, but be careful that your navigation, title, and action icons stand out against them. Make sure customizations don’t create a distracting experience, or compromise legibility. Maintain a good contrast ratio to support accessibility.

 

Choosing the right app bar for your app

So, app bars are an essential part of your app’s chrome and there are a lot of similarities in how Apple and Google handle them. With all that in mind, how do you make good choices for your own app?

The easiest option: Be comfortable and familiar for your users. You can never really go wrong with that approach, and that's what the UI guidelines exist for.

In a nutshell:

  • Use the regular (not large) app bar, using the default colours and font styling.

  • Include your app’s name or the name of the current view in the title area.

  • Include navigation elements in the app bar (e.g., “< Back” button or hamburger menu).

  • Include global actions like search or screen-specific actions in the actions area.

  • Hide the app bar when users scroll down.

When in doubt, going with these defaults will create an experience that’s familiar for your users. This translates to improved usability, and that’s nothing but good.

There are always exceptions. Here are some examples:

  • If your app is dead simple with a single view, you can omit navigation elements from the app bar.

  • If your app uses bottom tabs for navigation, you can omit navigation elements from the app bar.

  • If your app name is long, consider a “large” or “prominent” app bar.

  • If your brand identity is essential for establishing your app’s credibility, or if part of your app’s appeal is its design flair, then consider a large app bar with customized background and/or font styling.

 

Want more? Here’s my Component Round-Up: Top Bars (PDF), which shows some real-world examples and some of the common design patterns you can take from them.

Found something that doesn’t fit the mold but does a great job? Please share it!


  • linkedin
  • Facebook

©2018 | Corbet Fawcett | Usability - User Research - UX Design - UX Coaching | Canada

bottom of page