Intro

Optimizing your app for all window size classes requires a clear understanding of its structure and the relationships between screens. In compact size classes, users navigate through screens hierarchically, whereas in regular size classes, multiple columns can be displayed side by side.

Transformation from compact to regular size class

Starting with One Window Size Class

Begin by designing your app for a specific size class, such as compact, and make sure its layout is responsive and adaptive.

Creating an Information Architecture

Develop a hierarchical model that illustrates the structure of your app.

Identifying Related Screens

Look for screens that are closely related in the information architecture, such as a list screen and its detail view. These screens typically interact directly with each other.

Merging Related Screens into Columns

For larger screens, integrate related screens into a single display using multiple columns. For example, one column could show the list, while another shows the detail view.

Adjusting Designs for Different Window Sizes Classes

Tailor your design for various window sizes by considering the following questions:

• What needs to be displayed? Ensure that all essential details available in regular class are available in compact class, even if it requires an additional tap to view certain elements. For example, a filter might be shown beside a list in regular class but open on a new screen after a tap in compact class.
• How should the screen be divided? Determine the best way to split content across columns for different screens.
• What size adjustments are necessary? Adjust element sizes to fit different window sizes appropriately to make your app’s layout responsive and adaptive while maintaining visual coherence across devices.
• What needs to be relocated? Some components might need to be moved. For example, the bottom tab bar in compact size class moves to the side as a sidebar in regular size class.
• Which components should be exchanged? Replace certain elements better suited for specific class sizes. For example, a tab bar in compact size should be swapped with a sidebar in regular class.

Exchanging Components

Several components need to be exchanged in compact to a different component in regular size class.

Tab Bar and Sidebar

For distinct information hierarchies with a few primary destinations, it is best to use a tab bar in both regular and compact layouts.

For hierarchical and deep navigation, use a sidebar in regular and a tab bar in compact mode. The sidebar flattens the information hierarchy through primary and secondary navigation targets. Additionally, users can add shortcuts to their preferred content using the edit mode.

On large screens in landscape mode, the sidebar can be displayed alongside the content. In portrait mode or on smaller screens, the sidebar collapses to an icon. Tapping on the icon or swiping from the left edge opens the sidebar as an overlay on top of the content. Let the user decide to hide the sidebar to make room for content.

For iOS 17 or earlier, we recommend replacing the sidebar with a tab bar in compact size class. However, converting the sidebar to a tab bar requires manual effort from development. By default, the sidebar is retained in compact.

Mapping of Hierarchical Navigation Destinations

The sidebar allows you to show primary and secondary destinations, with secondary destinations placed under a collapsible section header.
The tab bar in compact size class only shows primary destinations. Secondary destinations are displayed in full-screen mode, allowing for further navigation.

For more information on how to convert a tab bar to a sidebar, see WWDC Video “Designed for iPad”.

For iOS18, iPadOS18 and vison OS2, the adaptable sidebar with tab view style has the following behavior:

• iOS 18: A tab bar at the bottom of the screen
• iPadOS 18: A tab bar that can be converted to a sidebar by the user
• macOS 15 and tvOS 14: A sidebar
• visionOS 2: An ornament, in addition to a sidebar for secondary tabs within a tab section.

Modal Sheet, Form Sheet, Fullscreen Modal, and Popover

Modality is a method to present content in a temporary mode to focus the user’s attention on a single task or set of controls. With adaptive design, modality on iPhone and iPad devices adapts to the screen sizes and uses the available space. A modal is often used for completing a task, updating content, or selecting filters. Depending on the task, the appropriate modal view should be chosen. There are modal and nonmodal sheets in compact size class, form sheets, full-screen modals, and popovers in regular size class.

Sheet in Compact and Form Sheet in Regular

For distinct tasks, such as creating or editing an object, it’s best to use a modal sheet in compact size class and a form sheet or full-screen modal in regular size class. In compact size class the modal sheets slide in on top of the parent page, and the parent page shrinks slightly. The form sheet in regular size class is placed in the center of the screen with a semi-transparent overlay underneath.

Sheet in Compact and Popover in Regular

For quick tasks that influence the parent view, such as filtering a list, it’s best to use a sheet in compact size class and a popover in regular size class. The sheet in compact slides in over the parent page. The popover in regular appears next to the area that activates it.

Nonmodal Sheet in Compact and Popover in Regular

Use a nonmodal sheet when you want to directly affect the main task in the parent view, such as when formatting a note. A nonmodal sheet covers only a part of the screen in compact size class, allowing users to interact with the content behind without dimming it. It is also possible to expand the sheet with an optional grabber or through scrolling. It adapts to a popover in regular size class. For more information, see Customize and Resize Sheets and Modals.

Sheet in compact and form sheet in regular size class

Sheet in compact and popover in regular size class

Resources

WWDC Video Design for iPad