Bringing Multitasking on iPad to the Udemy app

What if I told you that you can 4x the time your user spends in your app and 3x the number of app launches with just “one simple trick”? That’s not entirely clickbait. We did it at Udemy by supporting Multitasking on iPad.

No one can argue that how we consume content has drastically changed since the iPhone was unveiled on January 9th, 2007. More than a decade later, we have phones with screens more than twice the size of the first iPhone, we have laptops with touch screens and laptops with rotating keyboards to convert them to tablets, and we have the tablet that started the craze, the iPad.

“The average American watched 3.7 hours of live TV a day, whereas they spent 4 hours on their mobile device in H2 2020.” (App Annie, State of Mobile 2020)

Throughout the years as the screens became bigger and the devices became more powerful, the desire to do more with our mobile devices has grown proportionally.

Multitasking on iOS, a History

When iOS first launched, apps had a powerful single application model: one app running actively.

Apple had a clear goal here to simplify the user interface for the user, but it forced app developers to resort to tricks like frequent notifications to bring users back into their app and gamification to keep users within their app. In an ideal world, developers want user’s iOS devices to be locked to a single app: theirs.

Lucky for us developers, over the last decade Apple has catered to users wanting to do more with their device and gradually moved away from the single application model by introducing more and more multitasking capabilities.

Each iteration of Multitasking afforded apps bigger visual presence and permanence.

In particular with iOS 9, multitasking for iPad really kicked off — adding three new features:

1. Picture-in-Picture for video content
2. Slide Over to display a short-lived partial-screen multitasking experience
3. Split View to “pin” a Slide Over app for simultaneous interaction.

The last two features, Slide Over and Split View, combine to make up an experience called Multitasking and are especially monumental.

For the first time, apps were not limited to background activity or confined in limited app extensions. Two full-blown apps could run… simultaneously. This probably seems like a mundane concept for anyone who has ever used a PC which generally can run an infinite number of apps simultaneously, but this was a breakthrough in mobile-land.

And in iPadOS 13¹, the app in Slide Over no longer dismissed when interacting with the apps in Split View — allowing users to fully interact with up to three apps simultaneously.²

Amazing. You’re telling me I can have Facebook and my email app open side-by-side so I can slack off while I work?

Well… for the first four and a half years, the answer was no. And that’s because even though iOS supported these features, it was up to each developer to add support to their apps and Facebook didn’t do that until May 2020.

And Facebook wasn’t alone in this. For example the Amazon app still doesn’t support Multitasking on iPad in 2021.

At Udemy, our app supports Multitasking on iPad starting with version 7.0 (released in October 2020).

And, while we beat Amazon, we were not the fastest in bringing Multitasking on iPad to our users. And it wasn’t because our users weren’t asking for it, because they were:

I had a hard time convincing my team that I didn’t write these reviews myself.

So what was the hold up then? Well, since you’re already here, let me walk you through it.

The Beginning

The single application model mentioned earlier didn’t just simplify the user experience. It also simplified design and development. Committing to support Multitasking on iPad meant committing to support triple the number of window sizes across the entire app. It was a hard sell.

But I love iPad, and I believed there was so much untapped potential we could bring to our users with Multitasking for iPad.

And so I started thinking about how to tackle the challenges with solutions that wouldn’t be too costly for our team and how to package these solutions with the benefits of implementing Multitasking on iPad.

In the following sections, I’ll present excerpts of the pitch, starting with the benefits.

The Benefits

When thinking about benefits, there are two types to consider: qualitative and quantitative.

Qualitative benefits are:

• How will it benefit our users now?
• How will it benefit our users later, i.e. does this enable any future work?
• Does it give us a competitive advantage?

Quantitative benefits are:

• What metrics can we use to measure the impact of this feature?

Identifying the qualitative benefits was the easiest part. Many of our courses have natural applications for Split Screen, with note taking being the most obvious one.

Beyond pairing the Udemy app alongside a note taking app, other examples are:

• Using Swift Playgrounds with a Swift coding course
• Using a drawing app with a drawing course
• Using a photo editing app with a photography course

Examples of different learning experiences that are enhanced by multitasking support.

Additionally for future benefits, supporting Split Screen also means doing most of the hard work in supporting a potential Mac Catalyst app. The quantitative benefits were a little harder to estimate, but looking through analytics I saw that the average iPad user session was twice as long as user sessions on iPhone. I am not a statistician, but my conclusion from that metric was that our users prefer extended learning sessions on iPad.

Using my own anecdotal experience, I came up with an optimistic goal that implementing Multitasking would contribute to a 20% improvement in session time.

Now that we have some idea of what the benefits could be, let’s look at the blockers.

Unlike other multitasking features like Picture-in-Picture or background audio, Multitasking on iPad isn’t isolated to a single component of the app. The operating system requires complete support across the entire Udemy app. So to truly understand the scope of the work to support Multitasking in our app, I audited every screen in our app for each window size to identify any issues we would need to resolve.

We audited each screen to identify what broke for each possible window size.

Then, I aggregated the issues across the entire app to see if we could see a pattern between issues, orientation, or window size.

Landscape and compact width make up the majority of the issues.

In total, I flagged 67 issues in our app. In reality, a majority of these issues were the same UI element that broke across multiple window sizes. In particular, a majority of the issues occured when the window width was half or less than half of the full screen width.

In reality, a majority of these issues were the same UI element that broke across multiple window sizes.

So, if there was somehow a way to resolve similar issues across window sizes using the same tools, it would drastically reduce the cost to support Multitasking.

One tool we looked at was a feature of Auto Layout called readable content guides.

The Adaptivity app is great to visualize how the readable content guides adapt to different window sizes. It also supports Split View!

Readable Content Guides

Taken from Apple’s documentation:

This layout guide defines an area that can easily be read without forcing users to move their head to track the lines. The readable content area follows the following rules:

1. The readable content guide never extends beyond the view’s layout margin guide.

2. The readable content guide is vertically centered inside the layout margin guide.

3. The readable content guide’s width is equal to or less than the readable width defined for the current dynamic text size.

By aligning our content in Auto Layout to the Readable Content Guide, our content would be automatically padded for the current environment (window size and Dynamic Type setting). Best of all, the layout adapts to the new environment upon changing automatically, without a single line of code.

We first tried Readable Content Guides in our authentication flow and found it easy to adopt.

Of course, not everything in our app is centered in a single column.

UITraitCollection

In some cases we had to delve deeper with another tool called UITraitCollection. UITraitCollection is an object type in the iOS SDK that abstracts the iOS interface environment. Every UIViewController and every UIView have one, and UIKit notifies us when it changes.

UITraitCollection contains a number of different abstractions, like whether your app is in light or dark mode through UIUserInterfaceStyle or whether Dynamic Type is enabled through UIContentSizeCategory.

The abstractions that UITraitCollection provides that best relate to window and screen size (and the ones that we ultimately used) are UIUserInterfaceIdiom and UIUserInterfaceSizeClass.

UIUserInterfaceIdiom informs you to which platform is running your app (for example iPhone, iPad, or even CarPlay). While this doesn’t directly solve any issues for Multitasking, it’s useful as a parameter in layout logic and can be combined with UIUserInterfaceSizeClass.

Speaking of, UIUserInterfaceSizeClass is a pixel-agnostic way to describe window sizes. And like pixels that run both horizontally and vertically, UITraitCollection also has a corresponding UIUserInterfaceSizeClass for each direction.

For the direction that runs left and right, UITraitCollection has horizontalSizeClass.

For the direction that runs up and down, UITraitCollection has verticalSizeClass.

And, for each layout direction, there are two possible values: .regular and .compact.

Which value your app sees for horizontalSizeClass and verticalSizeClass depends on a few parameters: device, window size (split view mode), and orientation. While it might be daunting to try to design and develop interfaces for all permutations of these parameters, thinking in terms of regular or compact simplifies it tremendously.

Table taken from Apple’s Human Interface Guidelines showing the UIUserInterfaceSizeClass value for different Device, Split View, and Orientation configurations.

For example, on our Featured and Browse screens, our design says that the course cards should look one way on iPhone and look another way on iPad. This is because the screen width on iPhone is only a fraction of that on iPad.

But when the iPad screen width is reduced by the user through Split View, the iPad look may no longer be appropriate. This was true for us. In general, we wanted the app to layout with the iPhone layout when the width was constrained.

Using the Apple’s table, we accomplished this by using the iPhone look when the horizontal size class is “compact” and the existing iPad look when the horizontal size class is “regular”.

In some cases though, using size classes still didn’t have the precision we needed.

Precise layout computations with UIWindow

Looking at Apple’s table again, we can see that ½ split view and ⅔ split view both have Regular width in Landscape orientation on the 12.9" iPad Pro. But the width available to our app window in these two environments is drastically different.

Full vs. Half screen layouts for the course taking experience

For example, on the course consumption screen, we have the video player and the lecture list. In full screen, we have the video player with the lecture list on the side. But in ½ split view, there isn’t enough space to have this layout without it feeling cramped. And since ½ split view is still the .regular horizontal size class, we can’t use horizontalSizeClass here to determine which layout to use.

Instead, we wrote our layout logic to display an alternate layout with the lecture list below the video when the window size is less than or equal to 50% of the screen width; otherwise, we use the existing layout and place the lecture list to the side.

So, in addition to UIUserInterfaceSizeClass , we also have good ol’ mathematics in our tool belt.

A decision tree for deciding which tool to use.

In summary, we have automatic layout with Readable Content Guides, abstracted window sizes that we can respond to with UITraitCollection and UIUserInterfaceSizeClass, and (in rare cases) directly computed layout from UIWindow size.

By finding tools that make it possible to support Multitasking without needing to make separate designs for every possible window size, we drastically reduced the implementation cost without any compromise on benefits.

And so the project was approved.

Fast-forward to today, and the impact of enabling multitasking exceeded all our expectations.

To measure the benefits, we looked at 3 different groups of users:

• iPhone Users — Users that use iPhone
• Multitasking iPad Users — Users that use iPad and have used Multitasking at least once in the last 30 days
• Fullscreen iPad Users — Users that use iPad and have not used Multitasking in the last 30 days

From the above charts, we can see:

• User adoption continues to steadily increase.
• Users that use iPad Multitasking use the app almost 3x as often.
• Users that use iPad Multitasking use the app almost 3x as long.

The third point is staggering. It was above and beyond the 20% target goal we had set.

And each month we continue to see the improvement increase:

Even though we saw great improvements across the board that exceeded our expectations, there’s still room for improvement.

For example, the number of users that use iPad Multitasking is still much lower than the total number of iPad users. It doesn’t matter how great your feature is if users don’t know about it. Some ideas we have to tackle this include adding better onboarding material.

That’s not to say there’s nothing to celebrate.

As the world’s leading online learning destination it’s our prerogative to ensure learners have the ability to access and use our learning resources in the most user friendly and accessible format for them. I’m super proud of what we accomplished and I’m glad the analytics are showing that our users love the feature as much as we hoped they would. It proves that dedicating time to support platform features is worth the investment.

Special thanks to Patrick Heffernan, Linto Mathew, and Joseph Colicchio for their contributions in turning my writing into something comprehensible.

Footnotes

¹Apple reintroduced the iPad operating system as iPadOS, formerly iOS, with iPadOS 13 in 2019.

² Theoretically, users could have four apps if one of them could utilize Picture-in-Picture.