iOS Navigation Bar Design Guide

Rita Tavares
Air Apps
Published in
7 min readDec 9, 2020

As UI/UX Designers we come across a lot of elements that are made easy to use by various design tools. However, they are only visual and not all of us understand the depth and functionality behind a static UI element. That is what this article is here for. The iOS Navigation Bar has been with us since the first iPhone launch and has since been evolving, but before diving deep into the Navigation Bar we should first take a better look at the app architecture — more specifically — its navigation.

Hierarchical Navigation

The Hierarchical navigation style is the one used on Navigation Bars. In this style, the user moves from one screen to another, and the only ways to navigate are by going back or forward.

Navigation Bar Hierarchy

The navigation bar manages a parent and its child views, that are all connected. This means that any changes made to either the parent or the children will affect all the views. For example, the removal of the default navigation bar background that is very useful for a smooth display of the content scroll will be removed from all the views, and the result isn’t very soothing.

Consider that only one view is visible at a time. Tapping an item in the current view will push a new view on top of the previous one, whereas tapping the “back” button in the navigation bar will reveal the previous one again.

Example from BeLingual

Best Practices

In the Navigation Bar, the user’s current position in the hierarchy can be displayed in the bar’s title. An escape button is always provided that can be either labeled “Back” or the name of the view the user was previously in accompanied by a chevron that looks similar to the “less than sign”. It should always be made clear for the user where he stands and where he can go — the navigation should be clear and intuitive. Avoid having too many views inside the hierarchy — organize the app in order of having the least amount of views, and the least amount of taps to reach the desired content.

Another navigation style that has been on iOS since the beginning is Modality. This is a great way to present content to the user that is not included in the main flow. They are contextual and usually do not provide any navigation inside, focusing only on one specific objective to be concluded. Apart from presenting tasks, the modals can also help by displaying important information.

Modality presentations:
• Action Sheets
• Sheet Modal View
• Activity Views
• Fullscreen Modal View
• Alerts

Action Sheet / Sheet Modal View / Activity View / Fullscreen Modal View / Alert

Best Practices

Just like the Navigation Bar, the Modality should also have identifiable actions. The modal is presented outside of the user’s current flow, so the action to take must be clear. Choose a clear title that identifies what the modal is for, and always add an explicit exit button (Done and Close, at the right, or Cancel at the left since it’s a destructive action).

Example from Translate Now

Make use of this design technique wisely since taking the users out of their context is not the best option, unless it’s necessary. Provide this experience only when the user really needs to focus on making a decision that is outside of the current flow. Aside from using it only when necessary, they should also be very simple and clear. Letting the users navigate inside a modal experience can become confusing, since the path back might not be so clear. When going back, if there is content that needs to be saved, present an alert that helps the user choose whether he wants to keep it or lose it.

A navigation bar is usually placed at the top of the view, below (1.) the Status Bar, and contains 3 main components: (2.) a left item, (3.) a title, and (4.) a right item(s) (both 2. and 4. are optional).

This bar provides hierarchical navigation between views, and is one of the ways to prevent the user from getting lost inside an app. The navigation bar can be paired with (5.) a Search Controller and (6.) a Scope Indicator.

1. Status Bar

The Status Bar displays contextual information about the device, and it appears on the upper edge of the view. The elements that are usually in use are the time, the cellular carrier, the wifi connection symbol, and the battery level, but this information is influenced according to the device.

When designing, avoid using a custom status bar, since the system one is recognizable for everyone, and it feels consistent throughout all apps. The Status Bar can toggle between two states, light and dark, so choose the one that is more readable depending on the background. This bar should be visible most of the time (avoid hiding it permanently) since the user has to exit the app to consult the information that is displayed there.

2. Left button

This button is the easy path for the user to return to their previous location and it’s usually named after the view the user will go back to. It can also be named “Back”, but specifying the name of the previous view will make the path clearer.

3. Title

The navigation bar’s title displays the current position of the user which provides a little bit more context about what is being presented. However, the title can be hidden if it feels redundant or highlighted by using the large style, according to the content of the view.

4. Right button

The buttons that are placed on the right, can assist in managing and affecting the whole view, and they can be comprised of label or symbol buttons. The symbol buttons are usually about editing, sharing or adding options, but although it’s possible, consider not crowding this space with a lot of controls, since the space is limited and the user might lose focus. The label buttons that are usually used are “Edit”, “Done”, “Cancel” or “Close” (in this case only one should be selected)

5. Background

The default background of a navigation bar is a material (it is transparent and has a blur effect) and it shouldn’t be hidden, since it allows for the content to scroll seamlessly behind it. Disabling it is not advised since it will affect some accessibility options.

6. Search Controller

A Search Controller allows users to perform a search that is influenced by the content typed and can be displayed alone or in a Navigation Bar. When used in a Navigation Bar, it can be pinned to it and accompany the scroll or it can be hidden and only accessed with a swipe down. The Clear Button should be enabled to facilitate the content being erased faster. The Cancel Button should also be enabled to exit the search anytime.

7. Scope Indicator

A Scope Indicator contains two or more segments that can be helpful to separate the different categories in which to search. The number of segments should be no more than 3, considering the adaptability to smaller devices. The content should be consistent, meaning that all the options should occupy almost the same width of the segment.

Wrap up

We hope this can help you learn and avoid some mistakes on your journey. Feel free to visit our Navigation Bar Figma library. A huge thank you to the other Air Apps team members who contributed to the Figma library, Carmine Acierno and Yugi Aragão.

Leave us a comment if you have any questions. Or contact us at business@airapps.com

Thank you!

--

--