Architecting Your App for Multiple Windows
Description: Dive into the details about what it means to support multitasking in iOS 13. Understand how previous best practices fit together with new ideas. Learn the nuances of structuring your application to support multiple windows, and how to instantiate your UI, handle windows coming and going, and manage your app’s underlying window resources.
In the new scene delegate based lifecycle:
- app delegate should still handle things like initializing/cleaning up the whole process
- it should not however handle things like setting up the UI or updating it when the app goes into foreground/background - because this will now happen separately per session
- additionally, application delegate is now notified when a scene is created or discarded
- lifecycle delegate methods like
applicationWillEnterForeground
,applicationDidBecomeActive
etc. will not be called at all if scene lifecycle is enabled
Modern lifecycle flow
Starting the app:
AppDelegate
:didFinishLaunchingWithOptions:
AppDelegate
:_:configurationForConnecting:options:
->
UISceneConfiguration
- return configuration for the sceneSceneDelegate
:_:willConnectTo:options:
- this is where you set up your new scene
Scene configuration (UISceneConfiguration
): an object that describes the delegate class, storyboard etc. It's either built dynamically, or (better) statically described in Info.plist
and looked up by name using the constructor:
UISceneConfiguration(name: "Default", sessionRole: session.role)
Going to the background:
SceneDelegate
:sceneWillResignActive
SceneDelegate
:sceneDidEnterBackground
- …
SceneDelegate
:sceneDidDisconnect
- after some time, the system will release your scene (including the delegate object and all views and VCs) to save memory; you should now release any objects loaded to build that piece of UI
When the user force-closes a scene:
AppDelegate
:_:didDiscardSceneSessions:
(may be called on the next launch instead)
“State restoration is no longer a nicety”
Watch out for cases where a view controller needs to be updated if there are multiple scenes presenting the same view, which you might not have taken into account before - it’s better to only update the model and observe changes in the model, instead of updating the view directly when the user adds some new content.
- pro tip: you can pass Swift-only objects like enums in
NSNotification
if you use them as the sending object instead of inuserInfo
This note was originally published at mackuba.eu.