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 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 The point is that there’s usually some sort of system occlusion or reason why events would no longer go to your application.
From your blog post:
https://furbo.org/2025/06/28/ipados-windows/
> That’s because apps stay active even when their windows do not.
And the mastodon thread:
https://mastodon.social/@chockenberry/114761717903621566
> It’s not called when the window becomes inactive.
These statements are not correct from our perspective.
The first thing I installed after the WWDC25 Keynote was the beta for iPadOS. There was only one reason: it had the windows we have all wanted for so long. And generally, windows on iPad work exactly how we want them to. But there’s a problem, and I suspect that the root cause is that […]
@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 2) Active appearance on the phone
From what we can tell this is no longer reproducing on recent builds for iOS 26 or iPadOS 26. We took phone and pad apps on both systems and observed the change of UIUserInterfaceActiveAppearance when the scene was backgrounded to return to the Home Screen. We did not observe erratic behavior, but instead saw predicable changes from UIUserInterfaceActiveAppearance.active to UIUserInterfaceActiveAppearance.inactive.
@chockenberry If that’s not what you are seeing in recent Betas, please do give us more information so we can dig into that as that’s a bug.
Hope this helps!
@stroughtonsmith Just added this to the FB 😀
It's likely that the erratic behavior on the iPhone is caused by SpringBoard generating previews of the various application states.
Trying to outsmart SpringBoard is not something any developer should do.
Craig Hockenberry
joe kimberlin
Steve Moseley
Steve Troughton-Smith
Jeff