Hi Kevin, thanks for the quick response/suggestion! We tried submitting a replacement task with .queue when Camera expired the running task, but encountered a foreground-check error. Device: iPhone14,3, iOS 26.6.1 (23G83), externally powered. Our sequence was: While our app was foregrounded, register a unique replacement task identifier and create its request with strategy = .queue. Start the original task, background our app, then open Camera. In the original task’s expiration handler, submit the prepared replacement before calling setTaskCompleted on the original task. Close Camera normally after 90 seconds and observe for 15 minutes without reopening our app. In two valid trials, BGTaskScheduler.shared.submit(...) returned without throwing, but the replacement’s launch handler never ran. Our app process remained alive. Ordinary processing/refresh tasks ran separately. In the second trial, dasd logged this error for the exact replacement identifier at 2026-10-29 16:19:50.896323 UTC: bgContinuedProcessing-io.korom.krm.extended-hosting.A6008727-F8B5-423C-8C30-5E68965F03AD: Foregrounded apps (<private>) don't include expected identifier: <private> This looks related to the missing-error behavior discussed in thread 807370. We therefore aren’t treating the successful API return as proof that iOS actually admitted the replacement to its queue. Is queued resubmission from an expiration handler supported while the app is backgrounded on this iOS version? If so, what request/submission sequence avoids this foreground check? These tests used our ongoing-hosting app; we still haven’t established a standalone finite-work reproduction.

Hi Kevin, we’re investigating a reproducible Camera-related expiration and wondering whether it connects to the progress-reporting issues discussed here. On an iPhone14,3 running iOS 26.6.1 (23G83), we start a BGContinuedProcessingTask in the foreground, background our app, and open Apple Camera in Photo preview without taking a picture. Across six sequential trials on the same phone: The continued task expired in all six; our app process remained alive. Five captures explicitly identified Viewfinder Policy for the affected task. Settings, Calculator, Safari and video controls preserved the continued task. We directly advance task.progress.completedUnitCount approximately every five seconds. The largest locally recorded update gaps were about 5.5–5.6 seconds, so we aren’t relying solely on fractional child progress. The phone was externally powered with Low Power Mode off. UI automation and bounded system logging were active during the Camera tests. One implementation detail that may matter: our use case is ongoing community hosting. Progress currently tracks connected seconds, and we extend totalUnitCount as the session continues. We have not yet reproduced this with a standalone, finite-work sample, and we don’t want to assume that this ongoing progress model is supported. Is Camera’s Viewfinder Policy expected to expire a continued task despite regular progress updates? Could our progress model affect that decision, and what reproduction or diagnostics would best distinguish those possibilities?