Hi Folks, I have made some progress on understanding what is going on. Testing and debugging is quite challenging, but here are some observations: The handle:backgroundTasks: method of the WKExtensionDelegate never seems to fire in the simulator. You are at mercy of the system as to when the scheduled tasks will execute. This is by design, and will depend on conditions so it is hard to anitcipate when the requests will actually execute when debugging (i.e. don't expect the system to execute the task soon after the earliestBeginDate you have set for the task). There seems to be a type of "flush" of outstanding tasks when the app is activated and brought to the foreground. This leads to a bug in the sample code from the video. When these tasks are "flushed", there is no closure set (Set in the handle:backgroundTasks: method by calling the refresh method on the data provider (URLSessionDownloadDelegate)) which rescheduled the next background task. As such the polling mechanism is essentially breaks. So far, the solution is to only set the WKURLSessionRefreshBackgroundTask to complete in the closure and have the rescheduling done every time in the didCompleteWithError of the URLSessionDownloadDelegate. This may not be the optimal solution - Some additional investigation required for this.

moved