BGContinuedProcessingTask code pauses when device is locked

Question

Created 4w

Replies 4

Boosts 0

Participants 3

I have been experimenting with the BGContinuedProcessingTask API recently (and published sample code for it https://github.com/infinitepower18/BGContinuedProcessingTaskDemo)

I have noticed that if I lock the phone, the code that runs as part of the task stops executing. My sample code simply updates the progress each second until it gets to 100, so it should be completed in 1 minute 40 seconds. However, after locking the phone and checking the lock screen a few seconds later the progress indicator was in the same position as before I locked it.

If I leave the phone locked for several minutes and check the lock screen the live activity says "Task failed".

I haven't seen anything in the documentation regarding execution of tasks while the phone is locked. So I'm a bit confused if I encountered an iOS bug here?

Answered by DTS Engineer in 852891022

I haven't seen anything in the documentation regarding execution of tasks while the phone is locked. So I'm a bit confused if I encountered an iOS bug here?

It's possible there's a bug on our side as well, but the issue in your code is that you never call setTaskCompleted(success:) to finish the task. As far as the system is concerned, your task isn't "done" until you mark it complete, regardless of progress. That means it eventually fails due to lack of progress once your loop stops and the block returns.

Is it finishing properly while the device is unlocked? That's actually what's odd here to me.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

Engineer OP

Apple

4w

The documentation does say "The system can terminate a continuous background task abruptly depending on run-time conditions"

Of course both the documentation and the API are in pre-release state and the final state could be different than what you are expecting.

In any case, this is something our engineering teams should investigate.

We'd greatly appreciate it if you could open a bug report, include crash logs and sample code or models that reproduce the issue, and post the FB number here once you do.

Bug Reporting: How and Why? has tips on creating a successful bug report.

0

Answer 2

DTS Engineer OP

Apple

4w

Recommended

I haven't seen anything in the documentation regarding execution of tasks while the phone is locked. So I'm a bit confused if I encountered an iOS bug here?

It's possible there's a bug on our side as well, but the issue in your code is that you never call setTaskCompleted(success:) to finish the task. As far as the system is concerned, your task isn't "done" until you mark it complete, regardless of progress. That means it eventually fails due to lack of progress once your loop stops and the block returns.

Is it finishing properly while the device is unlocked? That's actually what's odd here to me.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0

Answer 3

rmahmud28 OP

1w

Sorry for the late response. Just got around to testing it on iOS 26 beta 8.

It's still the same as before, but when locked it doesn't always fail the task. But it remains paused and doesn't progress until I wake up the screen.

Feedback ID: FB19916760

I've also added setTaskCompleted(success:) and now it shows a tick when the background task is complete.

0

Answer 4

DTS Engineer OP

Apple

1w

Accepted Answer

It's still the same as before, but when locked it doesn't always fail the task. But it remains paused and doesn't progress until I wake up the screen.

Feedback ID: FB19916760

Thank you for that and this is definitely a bug. The API was intended to keep the device awake, but an oversight meant that if left off the assertion exception that prevented sleep, creating the odd behavior you're seeing. Note that the behavior here isn't directly tied to the device locking, so any other activity that keeps the locked device awake will also mean the task continues to run.

I suspect this is also why I haven't seen more reports of issues with this as LOTS of things prevent idle sleep, but in terms of development usage patterns and real-world device usage.

In any case, we'll either fix the assertion to keep the device awake (this is what I expect), or we're going to need to update the documentation to try and describe what's going on.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

2