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

Information Architecture

Organizing your app’s structure is key to building layouts that work on all screen sizes. A clear information architecture or sitemap is essential to spot areas for improvement and help your app scale in both compact and regular size classes. It is best to start by mapping the app’s current flow, then duplicating, and adjusting it for regular size class.

Initial information architecture showing the organization of an app

Best Practices

Identifying and Merging Related List Detail Screens

Identify screens that share a close relationship within the information architecture, such as a list screen and its detail view. These screens typically interact with
each other. For regular screen sizes, merge list screens and detail screens into one screen with multiple columns —one column displaying the list and another showing the details. Keep in mind that two and three-column layouts can’t be combined in the same app using SwiftUI class navigation split view. For this, a custom solution needs to be implemented.

Determining Presentation Modifiers

Identify use cases systematically and determine the most appropriate presentation modifier by referring to Usage Patterns. This guideline article outlines common scenarios and illustrates how they transition between size classes. For instance, a filter appears as a modal form sheet with a large detent in compact size class, whereas in regular size class it is presented as a popover.

Converting the Navigation

Convert the tab bar in compact to either a sidebar, a tab bar, or a sidebar adaptable style (from iOS 18 onwards).

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 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.

Creating Screens for Compact and Regular Size Classes

Based on the information architecture, create compact and regular screens. Choose the correct presentation modifier for your content as defined in the information architecture.

Reducing Navigation Hierarchies

Using the methodologies below reduces navigation hierarchy, allowing users to use fewer tabs in regular mode than in compact mode to access specific information.

• Presentation Modifiers: Some screens convert from a full-screen or modal in compact to a popover or inspector in regular.
  Instead of navigating to a new screen in compact, the popover is placed on top, and the inspector moves existing content to the side to show more information, which reduces one level in the navigation hierarchy.
• Sidebar: Tabs with list entries in compact can be converted to a group in a sidebar. The group header is equivalent to the tab name and the group items refer to the list items. With this approach, the list screen in compact is integrated in the sidebar and no longer required in regular size class, removing one navigation hierarchy in regular size class.
• Card Carousel: Showing more cards in a carousel in regular can eliminate the extra list which is needed in compact to show all items. We recommend making all items in a carousel accessible with three or four swipes. If there are two cards visible in compact, the user can reach up to eight cards with four swipes. In regular, four cards can be displayed. With four swipes, users can access 16 cards in the carousel. With a double carousel, these can be doubled to 32 cards.
• List Detail: Convert list and detail in compact to list detail screen. The list is placed next to the detail screen in regular.

Making Size Class Adjustments on Component Level

On regular screens, set each component’s size class to regular and choose the most suitable layout. Replace compact components with those that are more effective in regular size class. For example, instead of preview table views, use a multi column collection view with two columns, and prefer data table or card’s masonry layout over lists. Use the hierarchy view for deeper drilldowns.

Components may differ between compact and regular size classes, but users must be able to access the same information on both. For compact views, use progressive disclosure.

Multi-Window and Multi-Task in Regular Size Class

On an iPad, users can simultaneously view and engage with multiple app windows. Additionally, a single app can support multiple open windows, allowing users to interact with more than one window of the same app. See also Multitasking in Apples Human Interface Guidelines.
An application should not require multiple windows, but the application should support multiple windows and multitasking whenever it is useful for the user. The system automatically detects the best size class depending on the window width.
Anything that a user can drag and drop to a new window should be enabled for multitasking as the user expects it. For more see WWDC Introducing Multiple Windows on iPad.

Use Cases for Multi-Window and Multi-Task

• List/card carousels and details: drag and drop a list element or an element from a collection view in a new window to open the details. The list and the details are shown side by side on the current screen
• Compare: open two detail views side by side to compare two objects
• Create with reference: create a new object while keeping an existing object open for reference
• Task execution: Drag and drop your work items out of the list and create a to-do list. Each to-do is one window (6:39)
• Create attachments: create an attachment by dragging it from the source app to the destination app. The attachment can be a custom object, text, media, or document such as photo, screenshot, or PDF file. The destination app has to be compatible with the object that is dropped.

Resources

WWDC Video Design for iPad