BGProcessingTask expirationHandler - Do i MUST finish background work? or will it can be resumed later?

I'm building a BGProcessingTask that may take more then 5 minutes to complete. The processing task runs on a Singleton object that can be accessed (or even started) when the app is on foreground.

When the task expirationHandler is called, do i must finish my background work before calling task.setTaskCompleted(success: false)?

I would like to have the background work suspended not cancelled. So when i reschedule another background processing task later or the app moves to foreground the same background task will continue.

Is it ok practice? Will iOS might kill the background process (and the app) if not finished work before calling task.setTaskCompleted()? Or can i trust it will only get suspended and be able to resume later?

Kind Regards

Replies

When the task expirationHandler is called, do i must finish my background work before calling task.setTaskCompleted(success: false)?

No. You must complete the background task itself — if you don’t, you’ll end up killed by the watchdog — but your work can continue running. However, there’s a serious caveat here.

Once the background task ends your app is likely to be suspended. And once it’s suspended, it may be terminated. This can cause a variety problems.

The ‘obvious’ one is that your works needs to have some sort of checkpoint mechanism. That is, you need to perodically write your current progress to persistent storage so that, when your relaunched after a termination, you can continue you work from there.

Without this checkpoint mechanism you might see pathological behaviour. Imagine your work takes 35 minutes to run and every night BGProcessingTask gives you 30 minutes of execution time. You’ll do the same work over and over again and never complete O-:

The other thing to watch out for is much more subtle: You have to ensure that, when your app is suspended, the work is not holding exclusive access to some resource. In some cases the system is able to identify this issue and will terminate your app with the 0xdead10cc code [1]. However, that doesn’t cover all cases and so it’s possible to run into some truly weird problems here.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] See Understanding the exception types in a crash report.