scheduleBackgroundRefresh limitations

I am using watchOS4 and calling scheduleBackgroundRefresh() to update complications on the watch face.


I am scheduling a new background update every time handleBackgroundTasks() is invoked, and when I run in simulator with 5 min refresh intervals everything runs fine - noting that the simulator does not get rate limited.


However, when I run on actual device (typically with 15 min updates requested), I find that it runs fine for a number of hours (updates intervals seem to be 20m to 30m, but I can live with that), but then goes for many hours without receiving a background refresh call at all, before eventually resuming again. This happened overnight and I wondered if it might relate to watch being inactive or perhaps to do not disturb mode even. However, it eventually started receiving regular updates again (without any intervention on my part) but then entered a very long pause period again in the middle of the day - many hours without refresh.


Given the very long time periods involved it is near impossible to monitor via XCode debugging. So I am wondering what could cause such long periods without background refresh being called. My understanding is that with active complications, I should be receiving at least 4 updates per hour, and that there is no specific rate limit on calls to scheduleBackgroundRefresh().


I also note that my code may (potentially) make several calls to scheduleBackgroundRefresh during its background processing as I always firsly set it to 15 mins, but *may* make a sightly later repeat call to delay it further after I get data back and examine its validity. According to docs, making a subsequent call should simply cancel the previous call and replace it with one with the new request refresh period. One concern I have is that there is an unstated rate limit calls which might be counting my canceled background calls as part of a budget, which is a potential explanation for odd behavioiur I've noted.


I just can't understand the odd timings, and it makes for a pretty useless complication. Any ideas?!

Up vote post of gpdawson Down vote post of gpdawson
2.7k views
Posted by
gpdawson
Reply
Add a Comment

Replies

UPDATE:


After extensive debugging I've found that the main problem seems to be that just once in a while, my task to obtain updated data for the complications is terminated prematurely. This is presumably due to a timing limit that Apple refers to as "of the order of seconds". So when there is a slow connection or other connectivity my task is being dumped without allowing any cleanup code to run.


In fact I had my own download class to obtain the complications data, but now, because of these terminations, I've rewritten the code to be called in WKURLSessionRefreshBackgroundTask instead, in the hope that Apple won't terminate these prior to download completion.

However, others have reported, and I find similiarly, that WKURLSessionRefreshBackgroundTask are *never* called when run in the simulator. Hence all testing must be done on actual device. To make things harder, scheduled tasks run at unpredicatble times, and often long after they are actually requested, when called on actual device. This makes testing the new code excruciatingly time consuming, as I sometimes have to wait half an hour for a scheduled background update to actually occur (and probably made worse by fact that the actual device has rate limits and budgets that may be adding to these delays).


In particular see Daniel Fontes entries in this thread: https://forums.developer.apple.com/thread/52508

Posted by
gpdawson
Up vote reply of gpdawson Down vote reply of gpdawson
Add a Comment

Hey,


apologies for digging out this old thread. I'm currently attempting to create an AW complication that refreshes itself around every 30 minutes and have hit the exact same behavior that you are describing even in the new watchOS.


Have you by any means found a solution to consistently update a complication using background tasks?


The whole topic is still poorly documented and there's overall very little information.


Thanks a lot in advance and best wishes from Germany,

Axel

Posted by
Axel B.
Up vote reply of Axel B. Down vote reply of Axel B.
Add a Comment

Same problem here! The documentation is driving me nuts!

Posted by
Sorush
Up vote reply of Sorush Down vote reply of Sorush
Add a Comment

2021,WatchOS8,Same problem...OMG!Is Apple preparing watchos20 to solve this problem?

Posted by
AVAYA
Up vote reply of AVAYA Down vote reply of AVAYA
Add a Comment