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?