Multitasking and Multiple Windows

Multitasking lets people use the app switcher to switch quickly from one app to another and enables additional experiences on different devices. On iPhone, for example, multitasking lets people use FaceTime or watch a video in a picture-in-picture window while they also use a different app.

The app switcher displays all currently open apps.

A current FaceTime call can continue while people use another app.

On iPad, multitasking lets people view and interact with several different app windows at the same time. An app can also enable multiple windows, which lets people view and interact with more than one app window at one time.

iPadOS can present multitasking windows in a variety of configurations, supporting various workflows. The system also provides multitasking controls — which let people switch multitasking configurations — and the app shelf, which lets people access all open windows in an app.

Multitasking controls

App shelf

People can choose one of the following configurations to open multitasking windows on iPad.

Slide Over opens a second window in an overlay while the first window continues in fullscreen. People can change the onscreen location of the Slide Over window, or hide it offscreen and retrieve it later. People can also open multiple windows in Slide Over, where they form a stack.

Split View displays two windows side-by-side, letting people resize the relative areas of the windows and interact with both. While viewing side-by-side windows in Split View, people can also open a third window in Slide Over.

Picture in Picture opens a video in a movable, resizable window that floats above the fullscreen app.

NOTE Apps don’t control multitasking configurations or receive any indication of the ones that people choose.

People expect to use multitasking on their devices, and they may think something is wrong if your app doesn’t allow it. With rare exceptions — such as some fullscreen-only iPad apps — every app should work well with multitasking. For guidance, see Supporting Multitasking.

To help your iPad app respond correctly when people open it in Split View or Slide Over, make sure it adapts gracefully to different screen sizes; for developer guidance, see Multitasking on iPad. To learn more about how people use iPad multitasking features, see Use Multitasking on your iPad.

Beyond ensuring that your app works well with multitasking, you need to do additional implementation to support multiple windows. For guidance, see Enabling Multiple Windows on iPad; for developer guidance, see Scenes.

IMPORTANT To enable multiple windows in the Mac version of your iPad app, you must implement multiple windows on iPad. For guidance, see Mac Catalyst.

Supporting Multitasking

To thrive in a multitasking environment, your app needs to harmoniously coexist with other apps on the device, minimizing its use of CPU, memory, screen space, and other system resources. A multitasking app also responds well to sudden interruptions and audio from other apps, transitions to and from the background quickly and smoothly, and behaves responsibly when operating in the background.

Be prepared for interruptions, and be ready to resume. Your app can be interrupted at any time. When an interruption occurs, your app needs to save the current state quickly and precisely so people can seamlessly continue where they left off when they return. For developer guidance, see Responding to the Launch of Your App.

Pause activities that require people’s attention or active participation. If your app is a game or a media-viewing app, for example, make sure people don’t miss anything when they switch to another app. When they switch back, let them continue as if they never left.

Respond appropriately to audio interruptions. Occasionally, your app’s audio may be interrupted by audio from another app or the system itself. For example, an incoming phone call or a music playlist initiated by Siri may interrupt your app’s audio. When situations like these occur, people expect your app to respond in the following ways:

  • Pause audio indefinitely for primary audio interruptions, such as playing music, podcasts, or audiobooks.
  • Temporarily lower the volume or pause the audio for shorter interruptions, such as GPS directional notifications, resuming the original volume or playback when the interruption ends.

For guidance, see Audio.

Finish user-initiated tasks in the background. When someone starts a task, they expect it to finish even if they switch away from your app. If your app is in the middle of performing a task that doesn’t need additional input, complete it in the background before suspending.

Use notifications sparingly. Your app can arrange to send notifications at specific times, whether your app is suspended, running in the background, or not running at all. In general, avoid sending a notification when your app finishes a task in the background. Instead, let people check on tasks by returning to your app. For guidance, see Notifications.

Enabling Multiple Windows on iPad

Conceptually, iPad apps tend to use two types of windows to provide content:

  • A primary window presents the app’s full hierarchy, providing access to all of the app’s objects and the actions associated with them. For example, Mail uses a primary window to present all mailboxes and message lists.
  • An auxiliary window presents a specific task or area in the app, often using a modal presentation. Dedicated to one experience, an auxiliary window doesn’t enable navigation to other app areas, and it typically includes buttons people use to close it after completing the task. For example, Mail uses an auxiliary window to present a single message.

In iPadOS 15 and later, you can specify a presentation style that determines the initial appearance of each window that people open in your app. Although people can reposition a window after opening it, specifying a presentation style can visually reinforce the nature of a window’s task or content. iPadOS defines the following presentation styles:

  • Prominent. A modal presentation that elevates the window, dimming the surrounding areas and preventing interaction with them.
  • Standard. A side-by-side presentation that enables interaction with peer windows, each of which supports the app’s full functionality.
  • Automatic. A presentation that the system chooses based on the context in which your app requests the window.

NOTE If you simply need to let people view a file, you can present it without creating your own window, but you must support multiple windows in your app. For developer guidance, see QLPreviewSceneActivationConfiguration.

Use the prominent style to present a self-contained task people can complete without opening other parts of your app. For example, the prominent style works well to enable document editing or another task that’s scoped to a specific file or collection of content. Be sure a prominent window is also useful on its own; avoid using it to present secondary tasks, supplemental actions, or choosing items that affect the main task.

Use the standard style to present multiple versions of the same task or content. For example, Safari uses the standard style to help people view and interact with two browsing windows onscreen at the same time.

Open a new window only when people take an explicit action. For example, people can tap the Add (+) button in the app shelf or App Exposé, or choose a menu item. Avoid surprising people by opening a new window they don’t request.

Make sure your app window supports every task that you enable. Multiple windows can offer convenient and efficient workflows, but people always need to be able to access every app feature in a single window.

Preserve state in each window that people open. When people return to a window, they expect it to be in the same state in which they left it. For developer guidance, see Restoring Your App’s State.

Consider letting people use a gesture to open content in a new window. For example, people can use the pinch gesture to expand a Notes item into a new window. A gesture-enabled transition always uses the prominent presentation style, making the resulting modal window feel like a natural consequence of expanding the item or task. For developer guidance, see collectionView(_:sceneActivationConfigurationForItemAt:point:) (to transition from a collection view item) or UIWindowScene.ActivationInteraction (to transition from an item in any other view).

Consider providing a menu item that lets people open content in a new window. When you enable this behavior, the menu presents an “Open in new window” item when your app runs on iPad or on a Mac using Mac Catalyst, but not when your app runs on iPhone. If it makes sense in your app, you can supply an alternative item to display when the app runs on iPhone, such as “Show details...”. You can add an “Open in new window” item to a context menu or to menus attached to buttons and bar button items. For developer guidance, see UIWindowScene.ActivationAction.

Avoid specifying a layout when providing a way to open content in a new window. Because you don’t know which multitasking configuration people are using, avoid offering menu items like “Open in split view” or “Open in front.”

Always use the term window in user-facing content. The system refers to app windows as windows regardless of type. Using different terms — including scene, which refers to window implementation — is likely to confuse people.