Multi-window development in iPadOS
Let’s start off with some disambiguation. In iOS 11 Apple introduced split-screen multitasking support on iPad, which allowed two different apps to run side by side at the same time (with the end-user able to decide how much width of the screen each app took up). This feature didn’t allow the same app to run side by side with itself.
Note: split screen multitasking is something Apple will be requiring for iPad apps from April 2020.
In iPadOS 13 Apple are introducing multi-window support for iPad apps. This means that (if the app developer opts in) the end-user can run two windows of the same app side by side.
But beware. This isn’t two instances of the same app, it’s a single instance of the app but with two separate UI windows.
So how does it work?
As soon as you (the developer) enable multi-window support in your app there are changes to how notifications about the app’s lifecycle are reported.
This is because a new UIWindowSceneDelegate protocol has been introduced to simplify how the two windows of the app are handled as each window can go in and out of the background independently, rather than the app as a whole.
If you’ve not adopted this new UIWindowSceneDelegate then the app going in/out of the background is reported through the UIApplicationDelegate protocol and related notifications (as with iOS 12 and before), but as soon as you set up the UIWindowSceneDelegate the UIApplicationDelegate doesn’t receive any calls about going in/out of the background and the related notifications aren’t fired off.
Even if you’re not an app developer you need to be aware of this new API. If you develop a framework or code samples that app developers use then their switch to UIWindowSceneDelegate could cause issues for you if you care about lifecycle notifications.
So how do we deal with that?
Currently you might listen out for background-related notifications such as UIApplication.didEnterBackgroundNotification. If you switch to UIWindowSceneDelegate you can listen out for the new UIScene alternative, e.g. UIScene.didEnterBackgroundNotification.
But it’s not a 1–1 mapping. If a scene goes into the background it might mean that the user has just removed one of the two UI instances they were using, and the other is still in use and so the app itself hasn’t gone to the background.
To know if the app itself has gone to the background you presumably need to track how many scenes are currently active so you know when the last one has gone to the background, taking the whole app with it.
Other concerns?
Singletons can be problematic (you’ve probably heard that before!). You may have a singleton that has an array of some sort of limited resource that your UI will utilize. And your UI only allows that limited number of resources to be in use at one time, which was always fine in iOS 12 and below.
But now, if you have two instances of your UI, you need to make sure that it doesn’t end up allowing the user to attempt to use double the number of resources you’ve got available, so some refactoring could be required!
The delegate pattern that Apple relies on a lot could also be problematic. With two instances of your UI you may have two parts of your UI wanting to be the delegate of something at the same time and only one is allowed to be. I’m not sure if there are any examples from Apple that break in the case of multi-window but I know I’ve seen some in a codebase I frequent that will need refactoring in some way!
UIWindowSceneDelegate isn’t just for multi-window
It’s worth noting that UIWindowSceneDelegate isn’t just for multi-window support on iPad, it’s also useful for supporting external displays and CarPlay (see UISceneSession.Role), which therefore applies to iPhone and iPod.
So if you’re a framework-provider definitely look into it and make sure your framework plays nicely with an app that has started using it!
