Has WKExtendedRuntimeSession changed the way timers work in watchOS 10?

I have a stand-alone watchOS app that starts a WKExtendedRuntimeSession and a 1-second repeating timer when a button is pressed. No CPU-intensive stuff happens during this extended (background) time.

On watchOS 9, this worked perfectly until I stopped it again (or after the hour I get out of a Mindfulness Session Type has passed, and the extended runtime session expires). The screen could go dark, and the timer would keep running.

On watchOS 10, I get about 50 seconds when the screen goes dark, and then the timer just stops. No delegate methods are called (i.e. no "extendedRuntimeSession...willExpire()" or "...didInvalidateWith()" is called), though. Also, the scenePhase does not change at this point, it remains at inactive. The execution just stops. When I tap the watch to turn the screen back on, the timer resumes as if nothing happened.

Does anybody know what's going on here? Has something changed in WKExtendedRuntimeSessions in watchOS 10, or is it a bug?

I tried removing the timer and changing it to a recursive DispatchAsync.main.asyncAfter block, but it yielded the same result.

Accepted Reply

well, I found out what's wrong. It was my doing after all. CPU usage was way too high for some reason or another, and of course watchOS would terminate my app because of that. Deservedly so. So if you're from the future and reading this, this was the reason why WKExtendedRuntimeSession "didn't work" in my case.

Replies

well, I found out what's wrong. It was my doing after all. CPU usage was way too high for some reason or another, and of course watchOS would terminate my app because of that. Deservedly so. So if you're from the future and reading this, this was the reason why WKExtendedRuntimeSession "didn't work" in my case.