Multi-app multitasking for iPad in iOS 9: Explained

iOS 9 takes multitasking from the background and puts it right up front on the iPad.

Apple calls it Multitasking for iPad. The iPad, of course, has always multitasked at the system level, and over the years has gained background tasks and refresh and other forms of third-party multitasking as well. With iOS 9, however, the iPad is getting more than just the ability to do multiple things at once—it's getting the ability to show multiple apps at once. It's getting Slide Over and Split View.

Note: iOS 9 is currently in beta and governed by a non-disclosure agreement (NDA) that doesn't allow for screenshots or video. All the material contained in our iOS 9: Explained series is from previous, now public versions of iOS, from iOS 9 features shown off during the WWDC 2015 keynote, and from our coverage of the event, including our iOS 9 first look.

Multi-app multitasking basics

Both Slide Over and Split View allow you to have two apps on-screen at the same time—a "primary" app and a "secondary" app. The primary app is the one you start with, full screen. The secondary app is the one you bring in that either overlays a part of the screen in Slide Over or takes over part of the screen in Split View.

  • Slide Over lets you quickly access the secondary app as an overlay so you can respond to messages or mail, add to notes or check the web, or do some other, brief task while still keeping the primary app visible but not active.

  • Split View doesn't confine the second app to a side bar or a brief interaction, and doesn't make the primary app inactive. It lets two apps run at the same time, persistently, and gives you full access to both of them for the duration.

Because Slide Over doesn't let you interact with both apps at the same time, it has fewer system requirements and will run on iPad Air 2, iPad Air, iPad mini 3, and iPad mini 2. Because Split View does let you interact with both apps at the same time, it requires the more capable iPad Air 2 (and presumably future, even more capable devices.)

Picture-in-Picture, a third form of multi-app multitasking, is functionally different, so I'll tackle that in a separate explainer.

A brief history of iOS multitasking

When Steve Jobs first demonstrated the original iPhone in 2007, his music faded out, a call came in, he checked his mail and the web, the call ended, and the music faded back in. Since iOS (then iPhone OS) was built on the same foundations as OS X, it made total sense, but when the App Store arrived in 2008, third party apps didn't get to enjoy any of those multitasking benefits. If you switched out, or a call came in, the app simply quit, absent even a built-in way to save state.

That was due to Apple's obsessions with battery life, stability, security, and privacy. The company didn't want to simply turn on full UNIX-style multitasking since they believed it would result in significant power drain and require customers to manage tasks on mobile the way they had to on traditional computers. They also wanted to make sure personal data would be protected, and malware prevented.

Most customers didn't want full-on multitasking, though. What they actually wanted was to stream Pandora while surfing Safari, get TomTom directions while playing music, and receive Skype calls at any time. So, as part of iOS 4 in 2010, Apple released streaming audio, navigation, and VoIP application programming interfaces (API). The company also added the ability for apps to briefly complete tasks, save and resume state, and provided a push notification service, so customers could receive alerts even if apps weren't active at the time. It was limited but, for most people most most of the time, it was effective.

In 2013, Apple expanded multitasking in iOS 7 to include "all apps". That was done, in part, though background refresh. Using intelligent scheduling, opportunism, coalescence, and push triggers it created "just in time" updating for iOS. It worked because, most often, it doesn't matter when something happens as long as it happens before you need it.

Then, in 2014, Apple introduced Extensibility. Previously, app functionality was bundled into discrete binaries that sat on your Home screen. With iOS 8, Apple un-bundled that functionality and allowed features from one app to appear within another or within the system itself. Instead of leaving one app, hunting down a second, and then having to find your way back, you could quickly tap or swipe to share, act, filter, save or open, glance, reply, and then go right back to what you were doing. They could even extend themselves to other devices, like Watches.

All of this, from background tasks to app extensions, were done while maintaining battery life and ensuring security and privacy. Very little power was expended unless it had to be, and all data was kept strictly contained and never exposed while in transit between apps and services.

It would take more than just the ability to run multiple apps at the same time in order to get Slide Over and Split View to work—it would take the ability to show them.

A brief history of Adaptivity

Back in 2012 Apple ported Auto Layout (a system for constraint-based layout) from OS X to iOS 6. If you imagine the "guides" in iWork, the ones that let you snap one item into position relative to another, then imagine that those guides would never disappear, and could be saved as persistent "constraints", then that gives you an idea of the basis for Auto Layout: defining relationships. Rather than a pixel perfect painting that could never change, it was a structure that could reset frames, centers, and other layout elements automatically.

Then, with iOS 8, Apple introduced the idea of "size classes". Size classes have vertical and horizontal dimensions called "regular" and "compact".

  • The iPad in both portrait and landscape modes has the regular size class in both horizontal and vertical dimensions.
  • The iPhone in portrait has the compact size class for horizontal and regular size class for vertical.
  • The iPhone in landscape has the compact size class for both horizontal and vertical, except for the iPhone 6 Plus, which has the regular size class in horizontal (like a tiny iPad).

"Traits" control how elements of an interface change when things like device orientation change. "Trait environments" contain screens, windows, view controllers (layouts), views (what fill the parts of the layout), and presentation controllers (popovers, form sheets, modals, etc.).

Sometimes, like on iPhone apps, these all look indistinguishable because they all fill the screen. Other times, like on iPad apps, they're easy to see—a full screen filled with a split view overlaid by a popover.

"Trait collections" includes the horizontal and vertical size classes (compact or regular) and the display scale for any accompanying graphics (@1x, @2x, @3x), which can be collected into an asset catalog.

That's in addition to table views, collection views, and the new stack views and constraint conveniences—frameworks that grant a lot of adaptive behavior to developers "for free". And Launch Boards and the SplashBoardd process, which replace the old PNG-based splash image previously used determine which devices the interface would support.

Last year, Apple pushed the idea of "universal apps" hard—apps that used Auto Layout and had size classes for both the iPhone and iPad.

This year it's easy to see why.

When apps are adaptive they're not just ready for iPhone or iPad, but for iPad-style layouts on iPhone 6 Plus and iPhone-style Slide Overs and Split Views on iPad Air 2. In other words, apps are no longer device-based but are now size class-based, and they can transform from one to the other.

Just like the web evolved to responsive design, iOS evolved to adaptive UI as a way to make it easier for developers to manage and exploit multiple screen sizes, orientations, and densities, as well as different display sizes and, now, multiple window sizes as well.

iPad apps, orientation, and bounds

iPad apps traditionally work in both landscape and portrait orientation. In both modes, the horizontal size class is "regular" but there's a difference in how they're presented. For example, a typical split view app on iPad—UISplitView Controller, not the similarly named but different Split View multitasking—shows a master list view (a row of items) on the left and a detailed view (the contents) of the selected item on the right.

  • In landscape mode, the regular horizontal size class displays the list using roughly 30% of the left side of the screen and the content using the remaining 70%.

  • In portrait mode, the regular horizontal size class behavior varies. Mail, for example, lets you swipe the list view in or out, and will automatically hide it if you tap the content view. Messages, on the other hand, always shows the list view.

The exact behavior isn't important, however. That the narrower portrait mode for an app can behave differently from the wider landscape mode is what's worth keeping in mind. That's because, with iOS 9 and multi-app multitasking, those behaviors are no longer unique to those orientations. They now become a function not of device rotation but of window size—of being narrower or wider.

How Slide Over works

Slide Over shares some similarities with how the list view in Mail behaves in portrait mode on the iPad. It swipes in and out, and if you tap outside of it, it goes away. Slide Over also overlaps the same 30% of the screen in landscape and 40% in portrait.

The big difference, aside from Slide Over docking to the right side of the screen instead of the left, is that it doesn't contain the list view of the same app—it contains a different app.

To bring in a Slide Over, you swipe in from the right bezel. That locks out and dims the primary app and launches the secondary app. The primary app sticks with a regular horizontal size class and stays full width, but the secondary app comes in as a compact horizontal class on top of it. In essence, Slide Over is like an iPhone app in portrait orientation layered on top of an iPad app.

Slide Over apps work like iPhone apps as well. They're single column but you can scroll within them, swipe and tap, and move between hierarchies (lists items and their contents) and sequences (full window items) just like you would an iPhone app. And if you tap outside the Slide Over it goes away, and the primary app unlocks and becomes active again.

If you haven't used Slide Over in a while and the system isn't sure which app you want as secondary, it'll show you a series of icon tiles for each and every app on the iPad that supports multi-app multitasking. (Developers have to specifically add support; App Store apps won't appear unless and until they do.)

You can return to that interface, and switch secondary apps at any time, by swiping down from the top bezel and onto the Slide Over. Select a different icon and that icon's app becomes the new secondary app.

So, for example:

  1. You're using the Notes app in landscape mode on your iPad 2. Because it's the only app you're using, it looks just like it always has: two columns with the list of notes on the left and the current note on the right.

  2. Then you decide you want to check email. Since you're running iOS 9 on your iPad Air 2, you don't have to switch apps full-screen like an animal. You simply swipe in to bring up Slide Over and then tap the Mail icon. Notes grays out and Mail appears in the sidebar.

  3. Because Mail is only occupying 3/10 of the screen, it doesn't look like the traditional two-column iPad Mail app but instead looks like the single-column iPhone Mail app.

  4. Because you haven't used Mail in a while, Apple has smartly made the app show you your inbox to start. Once you tap a message, however, the list slides away, and the email fills the sidebar. Again, just like it does on iPhone.

  5. Next you need to check Safari, so you swipe down to bring back the app selector, scroll until you see Safari's icon, and then tap on it. Safari then fills the sidebar, and again it looks just like Safari on the iPhone.

  6. Done with Safari, you repeat the switching process to go back to Mail and this time, because you'd just been using it, it's smart enough to return you to the last message you'd been looking at.

  7. Once you're done, you swipe Slide Over away or simply tap outside its borders and you're back in full screen, fully active Notes.

And yes, it's as super-convenient for keeping up with messaging as you're thinking it must be.

How Split View works

Split View is more complicated than Slide Over because the exact behavior you get can vary depending on whether you're in portrait or landscape. Because of size classes, however, it's still all working off the same principles.

To enable Split View, you touch the grabber to the left of Slide Over app. That reactivates the primary app and also resizes it to fit the part of the screen not covered by the secondary app—roughly 70% in landscape and 60% in portrait. The secondary app stays in the same place, but settles down and gets a thick, black border to better separate it.

  • In landscape mode, the primary app stays with the regular size class but takes on the behavior of a portrait iPad app. In other words, if it's a split view app, the list view may or may not be persistently visible.

  • In portrait mode, the primary app transforms into the compact size class and shows either the list or the content view, like an iPhone app.

If you touch the border between Split Screen apps and drag it to the right, the primary app returns to full screen, and the secondary app disappears.

If you drag it to the left, the primary app disappears, and the secondary app becomes the new primary app, transforming to regular size class and taking over the full screen. (And then you can swipe to bring Slide Over back in; rinse and repeat.)

Landscape mode has an additional arrangement not shared by portrait: 50/50.

If you drag the border to the left in landscape mode, before you get to full screen, you can snap it to the middle of the screen. In 50/50, the primary app transforms to the compact size class while the secondary app remains compact class. Both still look like iPhone apps but are wider.

Since 50/50 exists only in landscape and not in portrait, if you're in 50/50 and you rotate, the Split View will change to the only portrait option, the roughly 60/40. If and when you rotate back, iOS will remember to return you to 50/50. (If you rotate from 70/30 you'll get returned to 70/30 as well.)

To change the primary app, you use the typical iPad app-switching methods: Click the Home button to return to the Home screen and select another app, double-click the Home button to bring up the fast app switcher and select another app, use the four-finger gesture navigation to swipe back or forth between apps, or tap on a link that opens another app. Whatever the method, the newly launched app will replace the primary app in the Split Screen setup.

Here's an example:

  1. You're using the Notes app in landscape mode on your iPad 2. Because it's the only app you're using, it looks just like it always has: two columns with the list of notes on the left and the current note on the right.

  2. Then you decide you want to check email, so you swipe in to bring up Slide Over and then tap the Mail icon. Notes grays out and Mail appears in the sidebar.

  3. After briefly checking a few emails, you decide you want to copy and paste some content between the two apps, so you tap the border, and they go into Split View.

  4. Mail settles down and Notes narrows to 70% of the screen and switches to a portrait iPad-style presentation. It also becomes active again, so you can easily scroll the list view, find the note you want and copy some content.

  5. Since Mail feels a little cramped, you drag the border out, and it snaps to 50% of the screen. It stays single column but feels roomier. Notes, however, transforms from portrait iPad-style to iPhone-style, but also roomier.

  6. You need to check something in Maps, so you click on the Home button, return to the Home screen (in full-screen mode), and tap on the Maps icon.

  7. Maps launches, but instead of going full screen, your Split View setup returns and Maps takes its place as the primary app, with Mail remaining secondary.

  8. Once you've found what you were looking for, you four-finger swipe on Maps and slide right back into Notes in the primary app space.

  9. After a while, you get really into emailing and want the full-on, full-screen experience, so you drag the border all the way across. Notes disappears, and Mail transforms into the standard two-column iPad app you've always known and loved.

And it stays that way, even when you swipe to pull Safari out into a Slide Over to just check one quick thing...

Developers and multi-app multitasking

Previously, an app could really only be used in one state: full screen. An app that supports multi-app multitasking, however, can be used in one of multiple states:

  • As a Slide Over or narrow Split Screen (30% in landscape, 40% in portrait)
  • As an equal Split Screen (50%, landscape only)
  • As a wide Split Screen (70% in landscape, 60% in portrait)
  • As full screen (100%)

Supporting it sounds like more work. If it makes sense of an app to do it, however, it makes sense for the developer to do it.

The stick is expectations: Because Apple's built-in apps already support multi-app multitasking, people will presume all apps will support it, and if not immediately then quickly. The carrot is usage: If supported, it'll make the app more convenient to use so people will use it more often.

The good news is that Apple has done a lot to make implementing multi-app multitasking easier.

  • New apps built for iOS 9 using Xcode 7 get iPad Multitasking enabled by default.
  • Existing apps need to make sure they're targeting iOS 9, that they support all four iPad orientations (portrait up and down and landscape left and right), and that they use Launch Storyboards. (Developers can also opt-out if they so choose.)

Because window bounds are no longer the same as screen bounds (i.e. an app can be running in Slide Over or as part of a Split View), point of origin for an app's layout (0,0) is now top left relative to the window and not the screen. That way, an app never has to worry about what side of the screen it's on or what other app is on the screen with it. It only needs to worry about itself.

Since people can swipe in Slide Over and resize Split Views at any time, however, apps need to be able to deal with those changes at any time. An app can't prevent a size change nor can it cause one on its own. Like the Home button being hit, an app has no control over a size change. It can only respond to them when and as they happen.

Being launched into Slide Over, for example, means an app needs to show an iPhone-like compact horizontal size class. Being pulled into 50/50 Split View means an app needs to elegantly expand into a wider compact horizontal size class. Being pulled into full screen means an app needs to elegantly transform into a regular horizontal size class. And vice-versa.

Auto Layout helps enormously with the former. Size classes with the latter.

For example, developers need to avoid hardcoding layouts as "portrait" or "landscape" now. Previously, resizing and rotating happened at the same time. Now an app can resize without rotating.

So, if an iPad is in landscape mode and you bring in a Slide Over app, that app will need to present its "portrait" version, not the "landscape". The good news here is that the same code that handles rotation-based size changes can also handle multitasking-based size changes. Any window that's not passed an explicit frame will also default to the correct size and automatically resize as needed.

To help maintain legibility, readable content guides automatically add extra margin space to keep lines from growing too long in full width and automatically tighten them up in narrower widths.

Table views, collection views, and the new stack views also do a lot of the adaptive heavy-lifting for developers. For presentation view controllers (like popovers and form sheets), Apple leaves them as-is for iPad-style regular horizontal size class windows but automatically transforms them into modal full-width screens for iPhone-style compact horizontal size classes. (The same way an iPhone 6 Plus in landscape can show an iPad-style form sheet instead of a modal full-width screen.)

There are a couple areas, however, where developers need to pay extra attention:

  • The keyboard can be called up by either the primary or secondary app. Developers can use the system's keyboard notifications to react to it being called up, even if it was a different app that called it, and move important interface elements out of the way just as they would if it had been called up by their app.

  • Because people can swipe in Slide Over and resize Split View at any time, developers can move and change content during the transition to help keep them oriented. If a two-column view is being compacted into a single column view, for example, developers can make sure the column that was last being used is the one that stays visible in the new state.

  • Non-sharable resources, like external or AirPlay displays, can only be used by the primary app. Since a secondary app can become a primary app at any time, however, if a notification comes in informing the app it now has a new, non-shareable resource, developers need to figure out how to best handle presenting that information so as not to cause confusion.

Then there's performance.


iOS and iOS apps are famous for rock-solid 60 frames-per-second (fps) performance. On early versions of the iPhone, Safari would famously stop rendering interface in order to keep up with interaction. These days, people expect to have both.

60 fps correlates to about 16 milliseconds (ms) to respond to an event. In a world where only one app can run on the CPU at a time, any app that responds in 9 ms is more than good enough. In a world where two apps (primary and secondary) can run at the same time, 2 x 9 ms is no longer good enough. Add a third app (picture-in-picture) and another 9 ms and frame rate drops and apps can appear to be lagging.

Memory is tougher still.

Again, in a world where there're only the system and one app running in the foreground at any one time, there's lots of headroom. Add a second app in the foreground, however, and that headroom gets smaller. Add a third app and it gets smaller still and maybe even runs out.

And when memory runs out, the system will jettison the primary and secondary apps and drop back to the Home screen.

To prevent this, developers can do several things. All of which involve trade-offs between memory and CPU, local and cloud, CPU and GPU, and memory and storage, and all of which come down to managing the "working set", or the critical objects needed at the moment.

By keeping the working set as small as possible and by smartly adapting when and as needed, developers can hopefully make sure their apps are the best multitasking citizens possible, and can live alongside other apps in Split View, even with a Picture-in-Picture video playing.


Apple has provided a bunch of resources for Slide Over and Split View multitasking for iPad:

Taking the iPad to the next level

Back in February I wondered out loud what could happen if the iPad was allowed to be its own thing: If, like the Apple Watch and Apple TV, it still ran the same systems under the hood, but got to present an interface that better took advantage of the unique capabilities of the device.Slide Over and Split Screen are the strongest signs yet that Apple may be willing to let it do just that.

You still can't have multiple windows of the same app if you want to, for example, more easily copy from one note to another. You also can't drag-and-drop content between apps yet either. But you can do a lot.

I'll save the details and assessments for my iOS 9 review, coming this fall when Apple ships, so for now I'll leave it at this—Instead of being "just a big iPhone", the iPad has become "two or three big iPhones", and that makes it exponentially more useful.