Hi all,
I’m seeing a lifecycle behavior change on iOS 26.0 (and up).
While my app is in the foreground and active, pressing the hardware Lock button triggers didBecomeActive callbacks/notifications even though the app is transitioning away from active state.
I’m observing this sequence: willResignActive didBecomeActive willResignActive didEnterBackground
This happens for: • UISceneDelegate.sceneDidBecomeActive(:) • UIApplicationDelegate.applicationDidBecomeActive(:) • UIApplication.didBecomeActiveNotification
On iOS 18 (same app, same code) I do not see didBecomeActive in the middle of locking/backgrounding.
Problem is reproduced on totally new project.
I would expect a normal transition to background: • willResignActive → didEnterBackground …and no extra didBecomeActive between them.
I have “became active” logic (refresh UI/state, resume timers, analytics). On iOS 26.0 this logic runs unexpectedly during locking, causing unnecessary work and incorrect state transitions.
-
Is this callback ordering expected on iOS 26.0 when pressing the Lock button?
-
If expected, what’s the recommended way to detect a “real” activation (and avoid transient didBecomeActive during locking/backgrounding)?
-
If this is a regression, is there a known workaround or best practice?