General: Forums subtopic: App & System Services > Processes & Concurrency Forums tag: Background Tasks Background Tasks framework documentation UIApplication background tasks documentation ProcessInfo expiring activity documentation Using background tasks documentation for watchOS Performing long-running tasks on iOS and iPadOS documentation WWDC 2020 Session 10063 Background execution demystified — This is critical resource. Watch it! [1] WWDC 2022 Session 10142 Efficiency awaits: Background tasks in SwiftUI iOS Background Execution Limits forums post UIApplication Background Task Notes forums post Testing and Debugging Code Running in the Background forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] Sadly the video is currently not available from Apple. I’ve left the link in place just in case it comes back.

We're seeing a high velocity crash with our users in background tasks in an internal Apple Framework. It seems to have started in iOS 17/18, but has increased heavily in iOS 26+. EXC_BREAKPOINT · 0 BackBoardServices -[BKSHIDEventDeliveryManager _initWithConnectionFactory:forTesting:] 1 BackBoardServices ___44+[BKSHIDEventDeliveryManager sharedInstance]_block_invoke 2 libdispatch.dylib __dispatch_client_callout 3 libdispatch.dylib __dispatch_once_callout 4 BackBoardServices +[BKSHIDEventDeliveryManager sharedInstance] 5 UIKitCore _stateMachineSpec_block_invoke_3 6 UIKitCore _handleEvent 7 UIKitCore -[_UIEventDeferringManager _processEventDeferringActions:actionsCount:inScope:forDeferringToken:environments:target:addingRecreationReason:removingRecreationReason:forReason:] 8 UIKitCore -[_UIEventDeferringManager _sceneWillInvalidate:] 9 UIKitCore -[UIScene _invalidate] 10 UIKitCore -[UIWindowScene _invalidate] 11 UIKitCore -[UIApplication workspace:willDestroyScene:withTransitionContext:completion:] 12 UIKitCore -[UIApplicationSceneClientAgent scene:willInvalidateWithEvent:completion:] 13 FrontBoardServices -[FBSScene _callOutQueue_willDestroyWithTransitionContext:completion:] 14 FrontBoardServices ___84-[FBSWorkspaceScenesClient _queue_invalidateScene:withTransitionContext:completion:]_block_invoke_3 15 FrontBoardServices -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] 16 libdispatch.dylib __dispatch_client_callout 17 libdispatch.dylib __dispatch_block_invoke_direct 18 BoardServices ___BSSERVICEMAINRUNLOOPQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ 19 BoardServices _BSServiceMainRunLoopSourceHandler 20 CoreFoundation ___CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 21 CoreFoundation ___CFRunLoopDoSource0 22 CoreFoundation ___CFRunLoopDoSources0 23 CoreFoundation ___CFRunLoopRun 24 CoreFoundation __CFRunLoopRunSpecificWithOptions 25 GraphicsServices _GSEventRunModal 26 UIKitCore -[UIApplication _run] 27 UIKitCore _UIApplicationMain 28 Aura main.m main 29 dyld start

I'm building a new app that uses the new background uploads extension, unfortunately, the App Store Connect process fails with the provided EXExtensionPointIdentifier. Invalid Info.plist value. The value of the EXExtensionPointIdentifier key, com.apple.photos.background-upload, in the Info.plist of “MyApp.app/Extensions/BackgroundUploadExtension.appex” is invalid. Please refer to the App Extension Programming Guide at https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/Action.html#/apple_ref/doc/uid/TP40014214-CH13-SW1. (ID: a471e5e7-361c-487f-8554-9deda472b2bc) Confirmed that both the app and extension targets are set to 26.1 minimum. What would be the best way to resolve/fix this?

I would like to know whether BGContinuedProcessingTaskRequest supports executing asynchronous tasks internally, or if it can only execute synchronous tasks within BGContinuedProcessingTaskRequest? Our project is very complex, and we now need to use BGContinuedProcessingTaskRequest to perform some long-running operations when the app enters the background (such as video encoding/decoding & export). However, our export interface is an asynchronous function, for example video.export(callback: FinishCallback). This export call returns immediately, and when the export completes internally, it calls back through the passed-in callback. So when I call BGTaskScheduler.shared.register to register a BGContinuedProcessingTask, what should be the correct approach? Should I directly call video.export(nil) without any waiting, or should I wait for the export function to complete in the callback? For example: BGTaskScheduler.shared.register(forTaskWithIdentifier: "com.xxx.xxx.xxx.xxx", using: nil) { task in guard let continuedTask = task as? BGContinuedProcessingTask else { task.setTaskCompleted(success: false) return } let scanner = SmartAssetsManager.shared let semaphore = DispatchSemaphore(value: 0) continuedTask.expirationHandler = { logError(items: "xwxdebug finished.") semaphore.signal() } logInfo(items: "xwxdebug start！") video.export { _ in semaphore.signal() } semaphore.wait() logError(items: "xwxdebug finished！") }

Hi, I have been recently debugging the BGContinuedProcessingTask API and encountered some of the following issues. I hope you can provide some answers: First, let me explain my understanding of this API. I believe its purpose is to allow an app to trigger tasks that can be represented with progress indicators and require a certain amount of time to complete. After entering the background, these tasks can continue to be completed through the BGContinuedProcessingTask, preventing the system from terminating them before they are finished. In the launchHandler of the registration process, we only need to do a few things: Determine whether the actual business processing is still ongoing. Update the progress, title, and subtitle. Handle the expirationHandler. Set the task as completed. Here are some issues I encountered during my debugging process: After I called register and submit, the BGContinuedProcessingTask could not be triggered. The return values from my API calls were all normal. I tried different device models, and some could trigger the task normally, such as the 15 Pro Max and 12 Pro Max. However, there were also some models, such as the 17 Pro, 15 Pro, and 15, that could not trigger the task properly. Moreover, there was no additional error information to help locate the issue. The background task failed unexpectedly, but my app was still running normally. As I mentioned above, my launchHandler only retrieves the actual business status and updates it. If a background task fails unexpectedly while the app is still running normally, it can mislead users and degrade the user experience of the app. Others have also mentioned the issue of inconsistent behavior on devices that do not support Dynamic Island. On devices that support Dynamic Island, when a task is triggered in the foreground, the app does not immediately display a pop-up notification within the app. However, on devices that do not support Dynamic Island, the app directly displays a pop-up notification within the app, and this notification does not disappear when switching between different screens within the same app. The user needs to actively swipe up to dismiss it. I think this experience is too intrusive for users. I would like to know whether this will be maintained in the future or if there is a plan to fix it. On devices that do not support Dynamic Island, using the beta version 26.1 of the system, if the system is in dark mode but the app triggers a business interface in white, the pop-up notification will have the same color as the current page, making it difficult to read the content inside the pop-up. Users can actively stop background tasks by using the stop button, or the system can also stop tasks automatically when resources are insufficient or when a task is abnormal. However, according to the current API, all these actions are triggered through the expirationHandler. Currently, there is no way to distinguish whether the task was stopped by the user, by the system due to resource insufficiency, or due to an abnormal task. I would like to know whether there will be more information provided in the future to help distinguish these different scenarios. I believe that the user experience issues mentioned in points 2 and 3 are the most important. Please help to answer the questions and concerns above. Thank you!

Hello, I'm trying to adopt the new BGContinuedProcessingTask API, but I'm having a little trouble imagining how the API authors intended it be used. I saw the WWDC talk, but it lacked higher-level details about how to integrate this API, and I can't find a sample project. I notice that we can list wildcard background task identifiers in our Info.plist files now, and it appears this is to be used with continued tasks - a user might start one video encoding, then while it is ongoing, enqueue another one from the same app, and these tasks would have identifiers such as "MyApp.VideoEncoding.ABCD" and "MyApp.VideoEncoding.EFGH" to distinguish them. When it comes to implementing this, is the expectation that we: a) Register a single handler for the wildcard pattern, which then figures out how to fulfil each request from the identifier of the passed-in task instance? Or b) Register a unique handler for each instance of the wildcard pattern? Since you can't unregister handlers, any resources captured by the handler would be leaked, so you'd need to make sure you only register immediately before submission - in other words register + submit should always be called as a pair. Of course, I'd like to design my application to use this API as the authors intended it be used, but I'm just not entirely sure what that is. When I try to register a single handler for a wildcard pattern, the system rejects it at runtime (while allowing registrations for each instance of the pattern, indicating that at least my Info.plist is configured correctly). That points towards option B. If it is option B, it's potentially worth calling that out in documentation - or even better, perhaps introduce a new call just for BGContinuedProcessingTask instead of the separate register + submit calls? Thanks for your insight. K Aside: Also, it would be really nice if the handler closure would be async. Currently if you need to await on something, you need to launch an unstructured Task, but that causes issues since BGContinuedProcessingTask is not Sendable, so you can't pass it in to that Task to do things like update the title or mark the BGTask as complete.

My app attempts to upload events and logging data when the user backgrounds the app (i.e., when applicationDidEnterBackground is triggered) by creating an uploadTask using a URLSession with a URLSessionConfiguration.background. When uploading these events after being backgrounded, we call beginBackgroundTask on UIApplication, which gives us about 25-30 seconds before the expirationHandler gets triggered. I am noticing, however, that the expirationHandler is frequently called and no upload attempts have even started. This might be reasonable if, for example, I had other uploads in progress initiated prior to backgrounding, but this is not the case. Could someone confirm that, when initiating an uploadTask while the app is backgrounded using a backgroundSession, there's really no way to predict when that upload is going to begin? My observation is that about 10-20% of the time it does not begin within 20 seconds of backgrounding, and I have many events coming from clients in the field showing as much.

TN 3115 states that apps that do not use AccessorySetupKit will loose the ability to launch into the background to service bluetooth in iOS26. Starting in iOS 26 and iPadOS 26, only apps that use AccessorySetupKit to setup Bluetooth accessories will be relaunched. Is there any more information regarding this? Will it affect any app under iOS26 or only those build against the iOS26 SDK? My app (dev build) is still relaunched, even though I'm running iOS26, so I wonder if there are any more conditions checked.

I have several combine pipelines in my watch and iPhone app. While background tasks on the iPhone work correctly (the combine pipelines all activate), on the watch the pipelines do not get activated. I have an internal log reporting that data is being fed to the sources but is not propagating to the sinks. Thoughts?

I've adopted the new BGContinuedProcessingTask in iOS 26, and it has mostly been working well in internal testing. However, in production I'm getting reports of the tasks failing when the app is put into the background. A bit of info on what I'm doing: I need to download a large amount of data (around 250 files) and process these files as they come down. The size of the files can vary: for some tasks each file might be around 10MB. For other tasks, the files might be 40MB. The processing is relatively lightweight, but the volume of data means the task can potentially take over an hour on slower internet connections (up to 10GB of data). I set the totalUnitCount based on the number of files to be downloaded, and I increment completedUnitCount each time a file is completed. After some experimentation, I've found that smaller tasks (e.g. 3GB, 10MB per file) seem to be okay, but larger tasks (e.g. 10GB, 40MB per file) seem to fail, usually just a few seconds after the task is backgrounded (and without even opening any other apps). I think I've even observed a case where the task expired while the app was foregrounded! I'm trying to understand what the rules are with BGContinuedProcessingTask and I can see at least four possibilities that might be relevant: Is it necessary to provide progress updates at some minimum rate? For my larger tasks, where each file is ~40MB, there might be 20 or 30 seconds between progress updates. Does this make it more likely that the task will be expired? For larger tasks, the total time to complete can be 60–90 mins on slower internet connections. Is there some maximum amount of time the task can run for? Does the system attempt some kind of estimate of the overall time to complete and expire the task on that basis? The processing on each file is relatively lightweight, so most of the time the async stream is awaiting the next file to come down. Does the OS monitor the intensity of workload and suspend the task if it appears to be idle? I've noticed that the task UI sometimes displays a message, something along the lines of "Do you want to continue this task?" with a "Continue" and "Stop" option. What happens if the user simply ignores or doesn't see this message? Even if I tap "Continue" the task still seems to fail sometimes. I've read the docs and watched the WWDC video, but there's not a whole lot of information on the specific issues I mention above. It would be great to get some clarity on this, and I'd also appreciate any advice on alternative ways I could approach my specific use case.

Hi, This post is coming from frustration of working on using BGContinuedProcessingTask for almost 2 weeks, trying to get it to actually complete in the background after the app is backgrounded. My process will randomlly finish and not finish and have no idea why. I'm properly using and setting task?.progress.totalUnitCount = [some number] task?.progress.completedUnitCount = [increment as processed] I know this, because it all looks propler as long as the app insn't backgrounded. So it's not a progress issue. The task will ALWAYS complete. The device has full power, as it is plugged in as I run from within Xcode. So, it's not a power issue. Yes, the process will take a few minutes, but I thought that is BGContinuedProcessingTask purpose in iOS 26. For long running process that a user could place in the background and leave the app, assuming the process would actually finish. Why bother introducing a feature that only works with short tasks that don't actually need long running time in the first place.

Hello, In a launched agent, I need to call into a third‑party library that may occasionally hang. At present, these calls are made from a separate thread, but if the thread hangs it cannot be terminated (pthread_cancel/pthread_kill are ineffective). Would Apple recommend isolating this functionality in a separate process that can be force‑terminated if it becomes unresponsive, or is there a preferred approach for handling such cases in launched agents? Can I use the system call fork() in launched agent? Thank you in advance!

When I use BGContinuedProcessingTask to submit a task, my iPhone 12 immediately shows a notification banner displaying the task’s progress. However, on my iPhone 15 Pro Max, there’s no response — the progress UI only appears in the Dynamic Island after I background the app. Why is there a difference in behavior between these two devices? Is it possible to control the UI so that the progress indicator only appears when the app moves to the background?

I am currently developing a macOS app that can show system HUDs in the Notch Till Sequoia I used to kill the OSDUIHelper process (which displays the default macOS Volume and Brightness control HUDs) - and replaced it with my app's HUDs But, it is not working on macOS Tahoe anymore as the OSDUIHelper process is no longer there due to the UI changes Has the process been renamed - or is there any other way to kill the process?

Hi All, I'm working on an app that needs to connect to BLE device and on defined schedules download data from the device. the amount of data is segnificant and might take around a minute to download. we tought about utilizing both state restoration and preservation for app waking and scheduling (triggered by the ble peripheral) and BGTaskScheduler to schedule a task that will handle a long running task to manage the full data download. now, will this solution in general valid? isnt it a "hack" that goes around the 10s limit that state restoration enforces? i know there are limitations for BGTask (like when it runs, it might be terminated by the system etc) but considering that, can we proceed with this approach without breaching apple guidelines? thank you in advance!

Hi, I have a couple questions about background app refresh. First, is the function RefreshAppContentsOperation() where to implement code that needs to be run in the background? Second, despite importing BackgroundTasks, I am getting the error "cannot find operationQueue in scope". What can I do to resolve that? Thank you. func scheduleAppRefresh() { let request = BGAppRefreshTaskRequest(identifier: "peaceofmindmentalhealth.RoutineRefresh") // Fetch no earlier than 15 minutes from now. request.earliestBeginDate = Date(timeIntervalSinceNow: 15 * 60) do { try BGTaskScheduler.shared.submit(request) } catch { print("Could not schedule app refresh: \(error)") } } func handleAppRefresh(task: BGAppRefreshTask) { // Schedule a new refresh task. scheduleAppRefresh() // Create an operation that performs the main part of the background task. let operation = RefreshAppContentsOperation() // Provide the background task with an expiration handler that cancels the operation. task.expirationHandler = { operation.cancel() } // Inform the system that the background task is complete // when the operation completes. operation.completionBlock = { task.setTaskCompleted(success: !operation.isCancelled) } // Start the operation. operationQueue.addOperation(operation) } func RefreshAppContentsOperation() -> Operation { }

Hello, I have a question regarding the behavior of BGProcessingTaskRequest when the app is force-quit by the user via the App Switcher. Based on common understanding and various discussions — including the following Apple Developer Forum threads: Waking up an iOS app after app is … | Apple Developer Forums Will BGAppRefreshTaskRequest will … | Apple Developer Forums Background fetch after app is forc… | Apple Developer Forums …it is widely understood that iOS prevents background execution (such as background fetch, push notifications, or BGTaskScheduler) after a user force-quits an app via the App Switcher. However, in my app, I have observed that a scheduled BGProcessingTaskRequest still executes even after the app has been explicitly terminated via App Switcher. The task is scheduled using submit(_:error:), and it is clearly running some time after the app has been closed by the user. That said, the task does run, but it appears to operate under tighter constraints — for example, it may be allowed to run for a shorter duration, and network requests appear to be more restricted compared to when the app is not force-quit. My questions are: Are there any documented or undocumented exceptions that allow this kind of behavior after force-quit? Could this be a bug or a behavior change in recent iOS versions? (I am observing this on iOS 18.3, 18.4, and 18.5) Any insights, experiences, or clarifications from Apple engineers or fellow developers would be greatly appreciated. Thank you!

First, our app communicates with our blood glucose monitor (CGM) using Bluetooth Low Energy (BLE). On an iPhone 14 Pro with iOS 26.0.1, Bluetooth communication works properly even when the app is in the background and locked. Even if the phone and CGM are disconnected, the app continues to scan in the background and reconnects when the phone and CGM are back in close proximity. It won't be dormant in the background or when the screen is locked. This effectively ensures that diabetic users can monitor their blood glucose levels in real time. However, after using iOS 26.0.1 on the iPhone 17, we've received user feedback about frequent disconnections in the background. Our logs indicate that Bluetooth communication is easily disconnected when switching to the background, and then easily dormant by the system, especially when the user's screen is locked. This situation significantly impacts users' blood glucose monitoring, and users are unacceptable. What can be done?

Hello, I'm trying to use multiple Background Assets Packs to host map tiles. This is problematic for a few reasons. MKTileOverlay requires a method that returns a URL. AssetPackManager.shared.url() throws, but it's unrelated to the url. It will return a URL even if it points to nothing. There's no name-spacing. Everything appears to be flattened. (See Error below) Simultaneously, this also is not the case as the documentation states: if there’s a path collision across multiple asset packs, then it’s undefined from which asset pack an individual file will be resolved. AssetPackManager.shared.url() doesn't have an optional parameter to explicitly declare the asset pack you want to access, like AssetPackManager.shared.contents(at: FilePath) does For example, I have multiple different tiles I'm trying to overlay for z: 10, x: 239, and y: 414. Foo/10/239/414.png Bar/10/239/414.png And even when explicitly stating the fold directory, it appears that the assets are flattened down. As I'm receiving this error. The URL for “Foo/10/239/414.png” couldn’t be retrieved: “414.png” couldn’t be copied to “239” because an item with the same name already exists.

Hello everyone, I’m a new developer still learning as I go. I’m building a simple watchOS app that tracks Apple Watch battery consumption, records hourly usage data, and uses that information to predict battery life in hours. I’ve run into an issue where background refresh completely stalls after charging and never recovers, regardless of what I do. The only way to restore normal behavior is to restart the watch. Background refresh can work fine for days, but if the watch is charging and a scheduled background refresh tries to run during that period, it appears to be deferred—and then remains in that deferred state indefinitely. Even reopening the app or scheduling new refreshes doesn’t recover it. Has anyone else encountered this behavior? Is there a reliable workaround? I’ve seen a few reports suggesting that there may be a regression in scheduleBackgroundRefresh() on watchOS 26, where tasks are never delivered after certain states. Any insights or confirmations would be greatly appreciated. Thank you!

Hi all, May I please ask for an official clarification or documentation reference from Apple regarding this scenario: Is it possible for an iOS app to automatically launch or open a specific screen when a push notification is received — while the app is in the background or terminated (killed) state? I understand that for most cases, user interaction (such as tapping the notification) is required before the app can show UI. However, I’d like to confirm whether this is also true for time-sensitive or critical alert notifications, including emergency use cases (e.g. public safety alerts). Specifically: Can a critical alert notification directly launch the app or present a view controller? Or is user interaction always required before the app can present any UI, even with the critical alert entitlement? I would appreciate if anyone — especially Apple staff or engineers — could share an official Apple document or statement that confirms this behavior. Thank you very much! (Use case context: I’m developing an emergency broadcast feature for a property management / tenant app.)