iOS 9 split-screen multitasking: Slide Over & Split View Quick Start (Chinese version)

Follow the instructions in this chapter to enable your app to run iOS 9 multitasking on supported iPad devices.
When you create a new Xcode 7 template project, Slide Over and Split View are supported by default. If you upgrade to iOS 9 from an older project, follow the steps below to set up your Xcode project configuration so that the app supports Slide Over and Split View:

• Set the Base SDK to "Latest iOS" as described in Setting the Base SDK in the App Distribution Guide.
• Provide a LaunchScreen.storyboard file (instead of a .png image file in iOS 7 and earlier). See Creating a Launch Screen File in App Distribution Guide.
• In the "Supported interface orientations (iPad)" array in the project's Info.plist file, declare that all four device orientations are supported, as shown below

Note: If you absolutely must not support Slide Over and Split View, explicitly add the UIRequiresFullScreen keyword to your Xcode project's Info.plist file and assign its Boolean value to YES. You can set this in the property list editor or in the General>Deployment Info area of ​​the target editor.

Tip: Users can disable Slide Over and Split View by going to Settings > General > Multitasking. If you have everything set up correctly but still can’t use these features, you can check this setting.

For more information on how to use Slide Over and Split View, you can download the Lister (for watchOS, iOS, and OS X) sample code project.

In Slide Over and Split View, both the primary and secondary apps run in the foreground at the same time, and in most cases they are equal. However, only the primary app can:

• Has its own status bar;
• Eligible to work with a second physical screen;
• Can use picture-in-picture automatic call;
• It can occupy 2/3 of the screen area in landscape mode, and in split view, it is a regular size class horizontally. (In horizontal Split View, secondary apps can occupy at most half of the screen and are a compact size class horizontally.)

In Split View, the user controls the size of your app's window. The user does this by rotating the device (as in earlier versions of iOS) or by horizontally swiping the vertical divider that separates the primary and secondary apps. The system notifies your app in the same way when both types of changes occur: changes to the window's bounds are accompanied by changes to the size classes of the root view controller. (Users moving split view controls also display app state transitions, described later in this section.)

Previously, iPad's horizontal and vertical Size Classes were always "regular". With the advent of Slide Over and Split View, this has changed significantly. The following figure shows the different Size Classes your app will encounter as the user manipulates the iPad screen.

In order for the app content to display correctly, your app must be adaptive. Your app settings should:

• Use Auto Layout and Size Classes as described in the Auto Layout Guide, Size Classes Design Help, and Simulating Screen Size and Orientation.
• This requires that the LaunchScreen.storyboard file in your app must support Auto Layout. New projects created using the App template in Xcode 7 automatically generate a LaunchScreen.storyboard file. To learn how to add this file to your project, see Creating a Launch Screen File in the App Distribution Guide.
• Implement methods in UITraitEnvironment and UIContentContainer to respond to changes in trait collection and size.
• Respond to app state transition protocol method calls as described in Execution States for Apps in App Programming Guide for iOS.
• Correctly handling your app's state transitions is especially important in iOS 9. In a Split View context, each time the user moves the Split View divider, both apps on the screen will move offscreen. This happens even when the user changes their mind and returns the divider to its starting point.

When the user moves the split control, the system calls the app delegate object using the ApplicationWillResignActive: protocol method.

The system will resize your app (offscreen) to capture one or more snapshots to ensure a smooth user experience when the user finally releases the divider control. This is because it is impossible to predict the final boundaries of the app window when the user finally releases the divider control. A more complex scenario is when the device rotates and moves the divider at the same time.

Make sure your app doesn’t lose data state or navigation state during the resize and snapshot process. That is, when a user resizes the app—moves a divider and moves it to its original position—and finally releases the divider, the user expects the app’s state and navigation position (including views, selections, scroll position, and so on) to be the same as when the user first touched the divider. Take advantage of the ApplicationWillResignActive: call to preserve the user’s state. For more information, read the What to Do When Your App Is Interrupted Temporarily section in App Programming Guide for iOS.

If the user moves the separator control until the screen boundary makes your app disappear, the system calls the ApplicationDidEnterBackground: protocol method.

For guidance on handling app state transitions gracefully, read Strategies for Handling App State Transitions in App Programming Guide for iOS.

For information about handling snapshots, read Prepare for the App Snapshot and refer to Capturing a View Snapshot in UIView Class Reference.