https://forums.developer.apple.com/forums/thread/685317 Having read the above discussion, I can add there’s one problematic exception on watchOS to the rule that .didBecomeActiveNotification is fired when the Control Center or any other overlay (such as a long-look notification) is dismissed. It’s when it’s dismissed not by the user, but just allowed to dsimiss itself after a period (as determined by Settings > Wake Duration). This is a problem for any Watch workout app because when one of these overlays is covering the app, it’s considered by the system to be backgounded for purposes of applying the 15% avg CPU load over 60 seconds criteria for being terminated for using too much CPU in the background, so I have discovered. In the case of these overlays covering an app, the app never gets a .didEnterBackgroundNotification call to know that it should attempt to reduce its activity, when the user presses the Side Button to show the Control Center, which is by design, as I understand it. The app does get a .willResignActiveNotification when the Control Center covers it, but there is no corresponding .didBecomeActiveNotification when the system dismisses the Control Center after 2 minutes or so. So if the app reduces its actvity in an attempt to reduce CPU load when covered by the Control Center overlay, it has no way to know it has become active again, in the special case of the Control Center timing out and being dismissed by the system. What could be done to reduce the likelihood of the system terminating the app in this situation, and maintain the app's functionality and usability?

My Watch app is a workout app that has to be careful to minimize CPU load when backgrounded to get below the 15% avg/60 s in order to avoid being terminated by the system. Accordingly I have logic to detect a transition to the background using a .onChange(of: scenePhase) { phase in… } handler which works well for cases where the app is backgrounded - it is able to reduce its CPU load to just 6-9% while backgrounded. But a special case of the change to scenePhase presents a challenge - when an overlay such as the Control Center or a long-look notification presents, there is no transition to .background, only to .inactive. This is a problem because the system nevertheless imposes the background CPU limit on the app while it’s being covered by the overlay, even though the app didn’t get the .background transition on the scenePhase handler. To further complicate matters, it now seems with watchOS 11 that whenever a transition is made in the screen cadence from .live to .seconds, the scenePhase handler is called with a transition to .inactive. Which is a problem because this transition has to be distinguished from the case of the overlay presentation - the cadence change has no CPU usage implications as long as the app remains foregrounded, but the overlay presentation does, and the system will terminate the app if it exceeds 15% avg/60s. My question: how can I distinguish between the two causes of the transition to .inactive for the two cases: 1) when the overlay presents, and 2) when the display shifts to the slow cadence?