Help Get Customers The Most Bang For Their iPad Buck With iOS 9 Multitasking

Since the first hardware was rolled 2010, the knock on the iPad has always been that it’s simply an oversized iPhone. While there have been some options which Apple has provided to help developers take advantage of the additional screen real estate like UISplitView, the iPad has lacked the ability to let users take full advantage of that real estate directly...until now. With the announcement of iOS 9, Apple added three new, iPad-only features that are designed to take advantage of the additional space, memory, and horsepower in a device that’s the size of an iPad instead of an iPhone: Picture in Picture, Slide Over, and Split View.

The first feature, Picture in Picture, is pretty self-explanatory: You can now watch a video and respond to work emails at the same time. One of the coolest things about this feature is how it utilizes all the same gestures as you’re used to. Is the video a little smaller than you wanted? Simply pinch and expand your fingers and the Picture in Picture will expand to your desired size (without a delay in the video that’s playing). Did you want the video in the upper right hand corner instead of the bottom left? Just tap and drag the video to your desired location. The Picture in Picture will seem to float over your other apps as you orchestrate your perfect environment.

 

Apple is very excited about this feature, and has given developers a great Quickstart guide to help them get started. Supporting picture-in-picture in iOS 9 is as easy as using the stock AVPlayerViewController or WKWebView classes, and making sure that your application has the appropriate background permissions. If you want to disable picture-in-picture for a particular video, there’s a flag which can be set on both of these classes so that video can only be watched within your application.

 

One thing developers can’t do: use Picture-in-Picture without explicit invocation from the user, or without allowing the user to control playback in the PiP window. Apple has made it crystal clear that it will reject apps that don’t meet these guidelines.

 

The second feature, Slide Over, makes it possible to open a second app in the same screen. With a quick swipe to the left from the right edge of your device (or vice versa when using a RTL language like Arabic or Hebrew), you’ll be able to pull up a list of your apps, then quickly open Twitter to tweet about the great article you’re reading. The big caveat with this feature is that you won’t be able to work on the app underneath until you dismiss the Slide Over. You also won’t be able to change the size of the window in this mode.

 

Slide Over support from a developer perspective is somewhat more challenging than PiP. First, you must be able to support any orientation with your app. Ideally, your app is already taking advantage of AutoLayout, Size Classes, or both, so that it can react to changes in the size of the screen automatically - whether caused by rotation of the device or the user firing up Slide Over. You also must be using an interface builder file for your launch screen instead of a static .png, and you must add implementations for UITraitEnvironment and UIContentContainer protocols so you can be notified when your application is being resized.

 

The far more complicated issue is that all applications in the foreground share the CPU, memory, disk I/O and GPU capabilities. That means if you want your app to work well with Slide Over, you have to make sure that your performance is optimized as much as possible so that you’re not stepping on another app’s toes. One of the big potential gotchas of needing this kind of optimization in all apps is that when your app is the primary app, the user might open up another app in Slide Over which is chewing through memory. In this case, it may wind up being *your* app which gets killed by the system instead of the misbehaving app.

 

Apple went into great detail in one of their 2015 WWDC sessions, Optimizing Your App for Multitasking on iPad in iOS 9, about how you can make your app a good multitasking citizen (and optimize your app for better performance in general as well). However, if you need to opt-out of Slide Over for any reason, you can set a boolean in your Info.plist file which tells the system your app requires the full screen. The system will then prevent the user from invoking Slide Over while your app is running.

 

Both Picture-in-Picture and Slide Over are available on the iPad Mini 2 & 3, as well as the iPad Air 1 & 2.  Unfortunately, if you’re still lugging around an older iPad, you won’t get any of these new features. But there’s one feature which is presently exclusive to the iPad Air 2 (though it will presumably be supported on newer hardware) which is truly impressive: Split View.

 

Split View is a way to use two apps side-by-side and simultaneously. If you need to work in multiple contexts at once, this is enormously helpful. While in this mode, you can pin two different apps next to each other. Now this ‘pinning’ is not just a one-size-fits-all trick. If you want two apps open at the same time, but you want one taking up half the screen, two thirds of the screen, or a third of the screen, you can now do this.

 

The main difference between Split View and any other tablet’s multitasking feature is that Apple has worked very hard to create a seamless experience. The content on each screen automatically resizes to fit whatever size the user requests. Any app which hasn’t specifically set the flag stating it needs the full screen can be opened in this mode. You can also alternate between Slide Over and Split View seamlessly. If you have the Slide Over open but you want to make it bigger, you can you can swipe it from Slide Over to Split View in one fluid motion.

 

From a development perspective, the challenges and details of supporting Split View are very similar to that of Slide Over. In fact, Apple’s multitasking Quickstart guide combines both of these features on the same page. The performance consequences can be even more severe since the system is under a tremendous amount of stress when running full versions of two apps simultaneously. This is why Apple has restricted Split View support to only its beefiest current iPad hardware.

 

How do you help your customers get the most bang for their iPad buck?

If you know that your app is going to be run in an environment which won’t support any of these features - for example, a corporation I’ll call LargeCorp which bought several thousand iPad 4’s when they came out - then you can hold off on adding multitasking support directly. You can still adapt Size Classes and AutoLayout to better support rotation handling immediately. This will have the added benefit of making your eventual work to add multitasking support a snap when LargeCorp decides to upgrade and buy several thousand iPad Air 3’s in a few months. 

 

If your app is targeted at consumers and the wide variety of devices they all have, start by evaluating whether you need to do work to support Picture-in-Picture. If your app doesn’t have any videos to show the user at all, you have a quick answer of “Nope!”. If you have some occasional video content in your app, you should evaluate the context in which the app is going to be showing those videos: Are they quick videos which it would make no sense for the user to watch outside of your app? Or are they longer videos which the user may want to watch while doing something else? The answers to these questions will help you figure out if it’s actually beneficial to your users to add support for Picture-in-Picture.

 

But for all consumer-facing iPad applications, updating your app so that it plays nicely with Slide Out and Split View is a great investment. By making your app able to handle all sorts of sizes, you make handling inevitable new Apple hardware that doesn’t match the aspect ratio of current hardware considerably easier. By optimizing your app so it doesn’t step on the memory, CPU, GPU, or disk I/O of other running apps, you provide a better, smoother experience to your user even when your app is the only one in use. You also reduce drain on the battery when your app is in use, something every user appreciates.

 

Overall, the more flexible you make your app’s user interface, the more ways your users can interact with it on their iPad. Users with newer devices will see the biggest benefit, but even an iPad 2 will benefit from the optimizations you make so your app plays nicely with others in a multitasking environment. Taking the time to make your app work with multitasking will help any user you have get the most possible bang for their iPad buck. 

This post was co-authored by Jen Kelley