The Navbar is Tapped Out

The UINavigationBar, navbar for short, has been around since the original iPhone. Historically, navbars have been convenient and clear, easy to understand and easy to build.

Then phones ballooned, enough that the iPhone 7 Plus supplanted sales of the iPad mini. Now, if you own a modern iPhone, navbars can feel unwieldy — literally out of touch.

Burgeoning screens mean the distance between the navbar and our thumbs has grown. The screen on a 7 Plus is so tall it would take a thumb-length increase of 150 percent to reach those pesky buttons with one hand. Just another knuckle or two. Nothing weird.

Hurff’s Touch Zones illustrate right-handed thumb reachability.

As devices change, our visual language changes with them. It’s time to move away from the navbar in favor of navigation within thumb-reach. For the purposes of this article, we’ll call that Reach Navigation.

Why the Navbar is Out of Touch

The Navbar is a mainstay of the “system standard” application, used in Phone, Messages, Mail, Calendar, and countless others. There are lots of reasons it gained favor:

• iOS Standard Apple built the navbar to be customizable, scalable, accessible, and easy to implement. Because it’s an iOS standard, it’s recognizable across apps.
• Navigation The left and right sides of the navbar afford space for buttons. The left area often navigates users up in the hierarchy, and the right area is up for grabs. The back button informs users that they’re not at the root view.
• Title Provides a consistent location for text defining the function of the view. Since the navbar always stays on screen, it helps further establish the information hierarchy.
• Companion to Tab Bar If you have a row of tappable icons at the bottom of the screen (namely, a Tab Bar), putting other icons at the top of the screen helps separate the parent/child relationship.
• Logo Your client can put a logo here! Genius. Lol jk, I find this tacky, but I digress.

Some sample navbars for your enjoyment.

Oh my gosh, so many great reasons to use a navbar in your project. Except, damn! It’s hard to get your thumb up there now.

That being the case, let’s talk some Navbar cons:

• It’s harder to go back. You can swipe from the edge, as long as the view you’re on doesn’t have anything that scrolls horizontally, but if it does then you’re in stretch-town.
• Naming all the views is a pain. Not all screens need a persistent title, and some require labels too long to fit. Leaving a blank navigation area wastes screen space and looks barren.
• Navigating requires two hands. If you can hold a device in one hand, you should be able to operate the device with one hand. It feels better, and it’s more convenient in a world full of shopping carts to push, and babies to carry.
• Simple apps become more complex than necessary. Navbars tend to lead to information architecture that runs deep. It’s easy to develop for horizontal progressive disclosure, which means it can be a battle to expand inline or use a sheet.

All right. Now we know how navbars can be crap. So what are we doing?

Reach Navigation and Apple

As an iOS designer, this is the part where I support my thesis by pointing out how Apple is already incorporating Reach Navigation. Ready? We’ll start with two of the obvious ways Apple is accommodating larger mobile screens.

In lieu of a back button, navigate back by swiping from the left edge.

First, you don’t have to hit the back button anymore, you can navigate back by swiping from the left edge. You can also control the movement of the screen as it swipes backwards, letting you peek at a previous screen before you commit. It doesn’t work in every app, but when it does you get to watch the back label transition into the title, which is just beautiful.

Lightly double-tapping the home button shifts content down.

Second, iOS includes a feature called Reachability, where your screen’s contents shift down to help you reach buttons near the top when you lightly double tap the home button. Workable for now, but it feels like a Bandaid solution.

Now here’s where the turn toward Reach Nav gets more apparent. Apple has already started weaning their apps off the navbar. Maps and Music both had structural redesigns for iOS 10 that diminished or removed the need for navbars.

Apple Music changes from iOS 9 (left) to iOS 10 (right). Removing the Navigation Bar allowed the primary view label to increase in size. Pretty.

Now both apps use a sheet you can swipe down to dismiss.

Apple Maps changes from iOS 9 (left) to iOS 10 (right). The UI is almost entirely inverted. Map Settings and Lock to Current Location are harder to reach, while Search and Results are prioritized.

A few back buttons in Apple Music survived the chop block for iOS 10, but they appear marked for removal in a future OS. It’s silly to earmark so much horizontal space for a button that only occupies 20 percent of the real estate. Apple Music has also reverted to a mere Back label instead of describing the return destination, a cornerstone of the back button’s functionality through the iOS 7 release.

The Back button in iOS 10 is taking up a lot of real estate here. Seems temporary, no? Yes.

So it seems like this is the direction Apple’s taking, which gives you a chance to shift your designs accordingly.

Incorporating Reach Navigation

Here are some specifics on how to incorporate Reach Nav in your apps. If you’re working on:

A new app using a Tab Bar:

• Use sheets that pop up from the bottom and can be swiped away.
• Instead of putting important buttons like Filter or Change View up high , see if you can float them above the Tab Bar.
• Have some conversations about which features are mission critical, before you choose tabs for your most precious screen real estate.
• Don’t put a destination button — like Search, Cart, New Message — in the navbar. Either make a tab or embed it in the content area.

A new app with no Tab Bar:

• Try an exposed drawer like Maps, or sheets like Mail.
• Do I need to say this? Prioritize placing buttons at the bottom of the screen.

A revamp of a legacy design:

• Move the most-used items to the bottom.
• Make sure swiping from the edge of the screen to go back works for all views.
• See what you can nest to free up space in the most usable screen areas.
• Remove important actions from the top right navbar spot, and put them anywhere else.

A quick rendition of how Safari could move the address bar to the bottom, remove the toolbar, and still maintain functionality.

Finally, there are a few exceptions on putting mission-critical buttons within easy reach. If an action has serious consequences, moving the button out of reach is a way to help your user avoid a mistake. So if a case of fat thumbs might cost someone thousands of dollars, or delete an important document, move those options up a bit.

Examples of Reach Nav in the Wild

New Apple apps aren’t the only products that are starting to respect Reach Nav. Lyft and Pokémon Go put everything within one-handed reach.

Pokémon Go and Lyft employ Reach Navigation.

Some other apps like Overcast have started using sheets that let you swipe down.

Overcast uses sheets that let users swipe down.

The iOS Twitter app removes the need to swipe from the edge of the screen to go back, now you can swipe from anywhere.

Expect to see more apps move functionality to the bottom on the most reachable part of the screen. It’s pretty easy to adapt, though apps with excessive features will have the most trouble.

Stay In Touch

The navbar has been essential part of iOS since Apple released the first developer kit, and it has served us well. But it’s time to let go.

Let’s agree to stop sticking important buttons to the top of the screen. Better navigation is within reach.

Brad Ellis is the founder of Tall West, a design agency whose clients include Airbnb and Target. He is an Apple Design Award winner, and has received two Webbys for app design. If you’d like to work together, drop him a line at Brad at Tallwest.com.

Contributors: Ronan Rooney and Maggie Mason