Pro Tip iPad Windows Special Edition™

If you use SceneDelegate to know when your app is active/inactive or foreground/background, you're going to need to look at that code on iPadOS 26: the delegate messages aren't called like on iPhone.

(Tip: set sound breakpoints in SceneDelegate and run your app to understand where they happen.)

You'll want to use a view's traitCollection to monitor activeAppearance, and do any syncing/backup when .inactive is detected. It acts like a Mac now.

Pro Tip iPad Windows Special Edition™ (Part II)

And, unfortunately, the view's traitCollection is not updated on iOS/iPadOS 18.

So now you're going to have two code paths for tracking your app's overall state.

Fun.

But we got what we wanted: Windows!

Pro Tip iPad Windows Special Edition™ (Part III)

This is going to catch a lot of folks off guard. Things like widgets not updating because you update a shared container when the app goes into the background are going to be super hard to track down.

If you look at the behavior of Stage Manager on iPadOS 18, it was trying to insulate apps from this behavior with the "task collections": you got delegate callbacks when those changed.

That no longer happens. Beware.

Pro Tip iPad Windows Special Edition™ (Part IV)

The "am I active or not?" question is not easy to answer in a way that works well on both iPhone and iPad.

The reason is that the iPad, with windows, reports activeAppearance predictably as windows become frontmost or not.

The iPhone, however, reports .inactive, then .active as you put the app in the background. When you return to the foreground, .active, then .inactive, then .active is reported.

So you save state returning to foreground…

Dupe this:

FB18443571: It's impossible to know when to save view state across platforms.

• SceneDelegate doesn't report activation/deactivation of windows on iPad.
• UITraitCollection activeAppearance changes are erratic on iPhone.

This is a huge problem: every app needs to save view state, sync changes, and perform other background operations when a user switches to another app or the home screen. There isn't a reliable way to know that this has happened in iOS 26.

@chockenberry Thank you for the feedback and apologies for the late reply! I think there’s a conceptual misunderstanding here as well as what seems to be a bug that may be resolved. More on each in the thread below.

@chockenberry 1) Activation state vs active appearance

The documentation and descriptions for UIScene.ActivationState.foregroundInactive and UIApplication.State.inactive are a bit opaque. Both say something like this:

> The app is running in the foreground but isn’t receiving events.

This can mean a lot of things:
- Control Center or Notification Center was presented over the app
- The app is foreground but the user has activated the App Switcher
- And more…

@chockenberry There is a difference between the scene visually being inactive as a user affordance and the actual lifecycle state of the UIScene instance.

From the perspective of the UIScene instance that’s on screen with another scene, both are (likely) UIScene.ActivationState.foregroundInactive. Tapping another scene so that the current one is no longer frontmost is _not_ the same as UIScene.ActivationState.foregroundInactive.

@chockenberry Because in many of those cases, you can still interact with the no-longer frontmost scene through scrolling with a pointing device or your finger.
@chockenberry Note that there is a difference here if you take one of these scenes and resize it to almost entirely occlude the other. Now the occluded scene will be UIScene.ActivationState.foregroundInactive because you are generally unable to interact with it.