I haven't experienced aggressive cancelation of my tasks unless progress doesn't advance in actual units. As I said about the bug I've filed, it seems the BGContinuedProcessingTask is ignoring the fractionCompleted property of the progress object. In my tests, the UI doesn't show any progress (just a spinning circle) unless units of progress are completed. I'm using child progress objects and only when a child object is completed and its units are set as completed in the main Progress object, the UI updates to show it. I've worked around this by manually adding completed units from the sub-Progress object instead of adding it as a child Progress... I've also seen that if this object is not updated with completed units regularly, then the system cancels the task unless your app is in the foreground. You don't even have to be using another app... If I make sure I add at least one progress unit to the object every 20s, I'm not getting the tasks cancelled. About the other matter (when to start your own work and not waiting for the BGContinuedProcessing task to start). I'm not sure if I'm understanding correctly. If you start your process and register the task separate from that, if/when the continued processing task is started, how can you communicate a change of title/subtitle? The actual task object inside the code block is not sendable. I guess you could at least report progress as the Progress object could be passed to another process safely, but I can't see a way to update the actual task from outside the registered code block...

First. Thanks for the detailed response. I've filed a bug about the progress reporting ( FB19925898 ) About the other matter, maybe I misunderstood the purpose of BGContinuedProcessingTask, but I think the fact that the user is the one starting the task is important... I don't see it as a way to finish some work in the background that was started in the foreground in a "normal" way, because when the work is started it has to be started from the BGContinuedProcessingTask itself. The actual work is done by whatever part of the code has to do it, yes, but it is started from within the block of code that is registered when creating the task. I think it makes sense to have a two way communication with the code doing the work so the UI can be updated in whatever way it is necessary... In my experience, larger work like that generally doesn't "neatly" fit with an individual task architecture, so the natural object to own your BGContinuedProcessingTask is the same object that's managing your tasks in the first place. In my case I first tried this approach but the object doing the work is an Actor and I couldn't find a way to start a BGContinuedProcessingTask from inside the actor. I had to force the actor to use a specific DispatchQueue but then when the task was active it blocked the actor. In the end I start the task from outside the actor (in a MainActor class) and then start the work calling an asynchronous function on the actor object. Thanks again! Jorge

Hello, I'm posting in this thread rather than starting a new one so all the information is consolidated... I also have some doubts about BGContinuedProcessingTask... My main problem is with the Progress object. I've observed that if I add children Progress objects to the object provided by the task, the popup that shows up with the task on the device doesn't update the progress interface until the Progress object has completed at least one unit. It doesn't seem to be using the fractionCompleted property and instead it seems to use the number of completed units. This is a problem because if I have a group of tasks to complete on one BGContinuedProcessingTask, the interface won't update gradually as the tasks are completed, but only in steps as each task completes and until the first one does it shows a spinning circle. Is this intended? or could it be a bug? Also, as the original poster said, the actual BGContinuedProcessingTask object is not sendable, so when I start an async Task there's no way to pass this object. It seems the only way to update the task is from the main block of code you register... And the only information that can be passed to this code is through the Progress object. Is that what's intended? Anyway, it's nice to get some information about this.It's a great new feature. Thanks in advance

I found the solution. I don’t understand why, but setting Reflection Metadata Level to All solves the issue. It was set to none in the other targets.

Just to be clear. I’m not using an extension. Everything is on the main app.

.directory doesn’t let me select folders. The picker only shows a cancel button. The urls seem ok and if I configure the picker to select files I can access them. It seems like a change from when the apple document was written because I’m only getting access to the selected folder and it’s file list.… thanks!!