Post

Replies

Boosts

Views

Activity

Reply to BGContinuedProcessingTask register block not called, submit does not throw an error
duet doesn't think your app is the foreground Fascinating! I can't think of any reason why, it's a straightforward implementation. As an aside, when this error occurs (the app isn't in foreground), BGTaskScheduler.shared.submit should throw an error right (but didn't here). Do you know what the user is doing when the trigger this? More specifically, is your app presenting the mail composer? It does but not in this flow. 2 seconds after the launch handler is not invoked nor an error thrown, I present an alert to inform the user an unexpected error occurred and there's a button to contact support. The user tapped that button to present mail composer ~30 seconds after the issue occurred according to default 2025-12-13 15:55:04.491796 +0000 AppName <MFMailComposeRemoteViewController: 0x124e7ac00>: Requesting remote view controller. The flow that triggers it is: User taps a button in the view controller's toolbar (Liquid Glass bar button item) to start processing App calls BGTaskScheduler.shared.register(forTaskWithIdentifier: taskIdentifier, using: .main) { @Sendable [weak self] task in App calls BGTaskScheduler.shared.submit(request) The launch handler is not invoked nor is an error thrown after 2 seconds so my logic is invoked to show the alert that tells the user to contact support It is also possible to get to 2 from an action in a UIAlertController that appears after step 1 and returns early if the app needs to ask the user how to process the requested items. In that scenario 1 is invoked, it returns early, shows the alert, user taps an action, and the function is invoked again and the alert won't appear that time. So the app can request background continued processing while an alert dismissal is animating. That did not happen in this case but figured I'd note it for completeness.
3d