Frank Rausch explains

Modern iOS Navigation Patterns beta

A critical part of using a digital device with a screen interface is navigation: Moving between views to find what you’re looking for without getting lost. Everyone who has used iOS for a while develops tacit knowledge of the platform-specific navigation principles. It matters, for example, whether a view slides in from the right or from the bottom. Animated transitions aren’t decoration—they explain the structural relationship between different parts of an app. This unofficial bonus chapter for Apple’s Human Interface Guidelines is intended as a complete overview of navigation patterns on iOS—something that Frank thinks is missing from the official guidelines.

Structural Navigation

The structural basis of a typical iOS app is a fixed information architecture—often a hierarchical tree that is several levels deep. The following structural patterns help the user navigate the app’s conceptual map. Following the hierarchical paths makes for predictable navigation—it prevents random jumping between arbitrary app sections. Ideally, you never end up in a different part of the app without understanding how you got there.

Drill-Down

Illustration of drill-down columns arranged horizontally to show the concept of cascading lists
  • The drill-down navigation pattern traverses an information tree structure as cascading lists—level by level, screen by screen.
  • Animated transitions convey horizontal movement between columns: Moving right goes deeper into the tree hierarchy while moving left goes back to the parent nodes.
  • Drill-down navigation is both stateless and modeless. Traversing the hierarchy should not be disrupted by asking whether to save data.
  • The Navigation Bar shows the current screen’s title.
  • Disclosure indicators () show that it’s possible to drill down deeper into the hierarchy, most commonly seen on table cells.
  • A back button () provides an obvious path back up the hierarchy. Its caption should be the parent screen’s title; not a generic “Back”.
  • Swiping right from the left edge of the screen has the same result as pressing the back button.
  • For right-to-left languages, the drill-down direction and control layout are mirrored to match the reading direction.
  • The tree structure may be constructed dynamically from a database. For example: In a music player app, you can find the same album through different paths and also through the search.
  • Drill-down navigation is the one-column-per-screen variation of macOS Finder-style Miller columns.

Flat

Illustration of an iPhone with a tab bar at the bottom and an iPad with a sidebar
  • The flat navigation pattern divides the hierarchy at the root level and shows them as a tab bar (or sometimes as a sidebar on iPad).
  • The tab bar items are curated around the app’s main capabilities to shape the user’s expectations and their mental model of what the app can do.2
  • One of the tab bar items is always selected.The active selection determines what’s shown in the main content area of the app.
  • The currently selected tab bar item should not change programmatically (without user interaction) or indirectly (e. g. by tapping a button elsewhere in the interface).
  • The tab bar remains visible on all screens throughout the app, except when it is temporarily covered by a modal sheet (see below).
  • Tabs can be used as filters or different entry points to the same large collection of content, like a library of music, videos, or photos.
  • Each section retains the navigation state for its own subhierarchy.
  • The infamous Hamburger Menu is the tab bar’s evil sibling: Discoverability suffers because the whole navigation interface gets hidden behind a little icon. Hamburger Menus were in vogue on iOS for a few years around 2015, but app makers ditched them when research showed that tab bars were much more discoverable.

Pyramid

Illustration of an overview screen with thumbnails and three sibling detail views with page indicators
  • The Pyramid1 pattern enables quick navigation among sibling views on the same hierarchy level—without having to go back to the parent screen.
  • The horizontal swipe gesture is a common way to switch between siblings in a media app. Buttons also work, like the Next Message and Previous Message chevrons in the iOS Mail app.
  • The iOS Photos app demonstrates the Pyramid pattern: Tap a photo to open them in a full-screen view, then swipe left and right to page through the adjacent pictures.
  • Use a page control for small collections to visualize the total number of items and the current item’s position relative to its siblings.

Hub-and-Spoke

Illustration of an iPhone home screen (the hub) and two apps (the spokes)
  • The Hub-and-Spoke1 pattern is ideal for larger collections of unrelated items at the top level of a hierarchy. Switching between the full-screen child views requires going back to the hub first.
  • The iOS home screen—a collection of all the installed apps—serves as a hub and a reliable “neutral state” of the operating system.
  • The home indicator at the bottom of the screen is an easy-to-learn and permanently available “escape hatch”1 that always leads back to the familiar home screen interface.
  • Note that this pattern is rarely used within apps. This is mostly here for completeness. We hardly ever need a conceptual separation as strong as the separation between apps at the operating system level.

Overlay Navigation

Overlays are easy to recognize: They are extra layers that cover part of the app. They want your attention. Unlike the structural patterns, overlays can appear over any context—even on top of other overlays! Modal overlays, on the one hand, require user interaction to dismiss them: They switch the app into a different mode, blocking the interface behind them. Non-modal overlays, on the other hand, don’t block the rest of the app—like notifications and other visual feedback from the operating system.

High-Friction Modal

Illustration of iOS modal sheets and a modal alert dialog box
  • High-friction modal overlays–such as sheets and alert dialogs with multiple actions–block the rest of the app.
  • A decision is required to dismiss them: A decision whether to save state; for example, whether to confirm (by tapping Done) or destroy (by tapping Cancel) the data you’ve entered into a form.
  • Modals are ideal to focus on completing one specific, self-contained task,2 like composing an email or adding a calendar event.
  • Stateful sheets and alerts with multiple actions are typical high-friction modals.

Low-Friction Modal

Ilustration a sheet and a full-screen media player, both with a simple close button. Illustration of a context menu and a popover on iPad.
  • Low-friction modals— such as sheets, menus, and popovers–block the rest of the app but do not require “either-or” decisions.
  • They are easy to dismiss: “Low friction” means not having to think much about how to get back. Pressing the close button or swiping down on a sheet, tapping anywhere outside of a context menu or a popover down—these modals go away with little effort.
Illustration of a modal alert dialog box with a message and an okay button as the only way to dismiss it
  • Alert dialogs with only an OK button are easy to dismiss, but they are not exactly low-friction. Not only are they annoying and potentially interrupting—people are so used to pressing OK that they won’t necessarily read the message.

Non-Modal

Illustration of an iOS system notification, the system volume feedback slider, and a non-modal palette sheet with a search field at the bottom of the screen.
  • Non-modal overlays cover part of the screen but don’t block the interface behind them. Because they are non-blocking (i. e. modeless), they cause little or no friction.
  • They may appear in response to a trigger outside the app like a notification from the operating system.
  • If they disappear automatically, they provide glanceable peripheral information with minimal interruption.
  • There may be optional functionality available in a temporary non-modal overlay, like tapping a notification or swiping on the volume indicator to change the volume before the overlay disappears.
  • If an overlay doesn’t block the rest of the app and doesn’t appear and/or disappear automatically, UI veterans from the 90s call it a palette.

Embedded Navigation

The following patterns require extra care to fit into the strict spatial flow of iOS without confusing the audience about where they are in the information hierarchy. It is best to contain or embed such a pattern in another view—one that sits in a clearly defined location in the app structure or in a modal overlay.

State Change

Illustration of the same screen in two states: The loading state and the loaded list state.
  • Navigation can happen within a view. For example, showing a loading state first and then the loaded items doesn’t change the position in the hierarchy.
  • Ensure that the state change really is neither hierarchical nor modal.
  • Be careful with full screen transitions for in-place state changes.
  • More examples: an editing state for a list; a web browsing interface; a panning map; a zoomable picture.
  • Having different view options for the same data on the same screen is also a state change that doesn’t change the user’s position in the hierarchy.

Step-by-Step

Illustration of two screen sequences with four steps each; a checkout sequence and an onboarding flow with next and skip buttons
  • The step-by-step pattern connects a series of screens in a linear flow. Typical examples are one-time guided tours and setup flows like onboarding, but also entering data in a series of forms, like a shop checkout.
  • Stepping back and forth in the sequence doesn’t change the hierarchy level. This is different from the drill-down pattern described above.
  • A step-by-step sequence should be contained in a modal overlay for presentation to emphasize that the back button serves a different purpose in this context than in drill-down.
  • The step-by-step process is usually finished with the last step and confirmed with a Done or Close button that also dismisses the containing modal.
  • The sequence may have a variable number of steps depending on the selected options.
  • “Wizard” and “assistant” are alternative names for this pattern.
  • Step-by-step flows can feel tedious. If you expect users to perform the process frequently, consider merging the steps into a single view with different states to increase the information resolution and reduce context switching.

Content-Driven

Illustration of three iPhone screen mockups showing hypertext with links, and arrows connecting all of the screens arbitrarily
  • Content-driven navigation4 (non-linear navigation, experience-driven navigation) means that a hyperlink or button can teleport the user to any other page or view. It’s how web navigation works in the browser.
  • Avoid this pattern in iOS apps, except for apps that show hypertext, immersive games, or similar non-linear content.
  • If you need to show hypertext content in an app, consider embedding it in a browsing interface with back and forward controls. A state change of a self-contained browsing interface is easier to handle than an unexpected location change in the app’s hierarchy.
  • The concept of links that take you to a specific place in the information architecture does exist on iOS: Deep Links1 take you from one app or from a website deep into the hierarchy of another app (using an URL Scheme or domain-tied Universal Links).

References

  1. Tidwell, Jenifer (2020). Designing Interfaces (Third edition). O’Reilly.
  2. Apple WWDC 2022 video: Explore navigation design for iOS.
  3. Apple Human Interface Guidelines (current)
  4. Apple Human Interface Guidelines (Archive.org, 2022-01-19)