iPadOS Windows Mess Up Data Saving

The APIs are there, it’s just no longer for the UIApplication[Delegate], but for UIWindowScene[Delegate]. These changes would have been necessary years ago, had apps supported more than one scene.

(Scene is the concept of “window” on macOS; it was necessary because Apple put themselves in a corner by abusing UIWindow in the early years of iPhoneOS/iOS.)

E.g.

https://developer.apple.com/documentation/uikit/uiscenedelegate/scenewillresignactive(_:)
https://developer.apple.com/documentation/uikit/uiscenedelegate/scenedidenterbackground(_:)

For apps that do not support multiple scenes (most apps), these behave just as the app-wide ones did.

@Leo, thanks for your first comment.

Last month I put updates to all my apps because of warnings in Xcode that SHOUTED AT ME that they weren't using UIScene lifecycles and that the warning would become an 'assert", in a future OS version. It took me testing, along with the "What's new in UIKit" session to actually gain some understanding. Apple has their own lingo, different than what I was raised with.

Apps instances have windows. (My lingo. And Microsoft too.) TextEdit can have open documents at once (but you have to open them one at a time and then choose the Megre All Windows option if you want them in one window with tabs). I'm pretty sure if I want my photo editing apps to have drag/drop, multiple windows on an iPad using iPd26 it can happen. (I cannot yet see how this can happen in iOS 26.)

Anyways... once I realized a UIScene lifecycle is *really* a window lifecycle, it clicked. Just didn't grasp the historical reason for this.

> (Scene is the concept of “window” on macOS; it was necessary because Apple put themselves in a corner by abusing UIWindow in the early years of iPhoneOS/iOS.)

Yea and imo not a very good one. Would’ve been much better to get an API like UIWindowController that would’ve been more like NSWindowController.

Think they were drunk when they came up with the API to programmatically create a “window scene.” Instead of a one liner -showWindow: call they made it some kind of weird request. Pretty sure they copy data you pass to the new scene with NSUserActivity which was (is) completely unnecessary because you’re in the same process (been awhile since i did this though). passing custom objects is especially annoying.

You pass your data to the activity and read it from the user activity in the window scene delegate methods on creation on the “other end.” Fucking whacky API. Who comes up with this shit
—
From the blog post:
“ There is an API in iPadOS to track the state of each window: it has an “active appearance” that tells you when the window has focus. Unfortunately, on older versions of the OS, nothing is reported for this state, so backward compatibility is a problem. Also, on iOS 26, the active/inactive window state changes unpredictably while an app is off screen: my suspicion there is that the OS is taking screenshots to use in the App Switcher.”

That’s interesting. “Hide to sync”. Dont know anything about iPadOS 26 yet but i have multiscene app. Cant remember what i did off the top of head but i don’t recall having a problem with background tasks in multiscene apps on older versions of ipadOS

I think in sceneDidEnterBackground i enumerated the window scenes (all of them) and checked the activation state or something. If no foreground scenes were found basically triggered the code that you would have done in -applicationDidEnterBackground in a single “scene” app.

Do we need a -applicationDidResignActive: callback on ipadOS 26 for new window behavior? Does UIApplicationWillResignActiveNotification get posted when you have window scenes visible but you’re not the active app?

Just port AppKit to ipad Apple. Time to do Catalyst in reverse

You can already have multiple “windows” (=scenes) already on iPadOS with drag and drop. See Safari. The API for multiple scene support is somewhat convoluted, especially opening a new scene programmatically (the user can tap a + button in the Exposé equivalent to open a new “window”). On macOS, you just create a window, unhide it and perhaps make it key. If you want to be fancy, you also have a window controller. It’s so easy. On iPad, they don’t want a random window to be stand alone, so the scenes require manifests and what not. A real mess.

Historically, Apple wrote in their docs for UIWindow that only a single instance should be used. But in typical Apple fashion, they just abused it to hell. For example, the keyboard, the old context menus (UIMenuController), dictionary (Look Up), even the cursor, selection and the loupe in some versions of iOS, would sit in separate UIWindow instances. This is still true today. If you pause using the visual inspector in Xcode, you can see this is still the case. And other people started using UIWindows too:
https://github.com/LeoNatan/LNWindowManager

So come multiple “scene” time, they had a problem; either they had to break existing apps and their own implementations, or they had to come up with a different concept. So they borrowed from Frontboard and called them “scenes”.

@Leo, understood. iPadOS (something when first had a delayed into for a month and Apple claimed on a support phone call is the same as iOS)) supported D&D. But for me this is different (and better). Still sandboxed somewhat though. But any day they give me a way to open two images *and* copy/paste anything is better than what iPad (and maybe iPhone?) has right now.