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 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！") }

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?

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.)

Hello, I’m developing a HealthKit-based fitness app in React Native that observes step count changes and uploads the latest totals to a remote server. I’m currently using HKObserverQuery with background delivery enabled (enableBackgroundDelivery(for:frequency:.immediate)), and the behavior works correctly while the app is running in the background or foreground. Whenever new step data is written to HealthKit, the app wakes up, reads the latest data, and sends it to my HTTPS endpoint using URLSession.shared.dataTask inside the observer callback. However, I’ve noticed the following issue: 1. If the user swipes up (force-quits) the app from the app switcher, the observer queries stop firing entirely. 2. In this state, even though HealthKit continues collecting step data from the device or Apple Watch, my app no longer receives those background deliveries until the user opens the app again. What I would like to achieve is: When the app is terminated (swiped up), and there are new step count updates in HealthKit, my app should still be able to receive those updates or be relaunched to handle them — similar to how some health companion apps continue syncing data and sending notifications even after being force-quit. So I have a few questions: Is this limitation expected — i.e., does iOS intentionally block HKObserverQuery background deliveries after a user force-quits the app? 2. Are there any special entitlements, background modes, or Apple-approved mechanisms that allow a health or medical app to continue receiving HealthKit changes even after a force-quit? 3. If not, what is the recommended architecture for apps that need to process HealthKit data continuously and send it to a backend server? For example, should such apps rely on server-side push notifications or CloudKit sync once the user reopens the app? My current goal is to ensure step count changes are uploaded reliably even if the app is killed, but I want to stay within the system’s supported behaviors and privacy constraints. Any clarification or guidance from Apple engineers or others who have implemented continuous HealthKit sync (like companion or medical apps) would be greatly appreciated. Thank you.

Hello, My watchOS app has been performing fine by requesting background app refresh and then requesting any new data from health kit in the background so that the widget can be updated. However, on watchos26 I have been unable to read data in the background, with any query returning zero results. That same data is clearly read just fine while in the foreground. Can anyone assist?

Issue: I am making an application that stores data locally from notifications fired from the server. Everything works fine in the foreground but the background is having problems with not being triggered when notifications are fired. So we tried firing 2 notifications at the same time, including default and silent types. But the problem continues to arise on ios 18, when firing multiple times like that, the trigger is not handling all notifications, leading to data loss. I tried on ios 15 and it worked fine. Environment: Device or Simulator: Iphone 11 pro max (iOS 18.3.2 Steps to Reproduce: Open app, allow received notification. Move app to background mode or terminate app. Sent 2 notifications: a. Default notification payload: { "aps": { "content-available": 1 }, ”notification”: {…}, “alert”: {..}, “data": "some_value" } b. Silent notification payload: { "aps": { "content-available": 1 }, ”data": "some_value" } What I've Tried: Trigger notification in function: application(_:didReceiveRemoteNotification:fetchCompletionHandler:) Handle write data to local storage in above function, put it in background thread also. Thanks in advance!

I'm trying to understand how the API works to perform a function that can continue running if the user closes the app. For a very simple example, consider a function that increments a number on screen every second, counting from 1 to 100, reaching completion at 100. The user can stay in the app for 100s watching it work to completion, or the user can close the app say after 2s and do other things while watching it work to completion in the Live Activity. To do this when the user taps a Start Counting button, you'd 1 Call BGTaskScheduler.shared.register(forTaskWithIdentifier:using:launchHandler:). Question 1: Do I understand correctly, all of the logic to perform this counting operation would exist entirely in the launchHandler block (noting you could call another function you define passing it the task to be able to update its progress)? I am confused because the documentation states "The system runs the block of code for the launch handler when it launches the app in the background." but the app is already open in the foreground. This made me think this block is not going to be invoked until the user closes the app to inform you it's okay to continue processing in the background, but how would you know where to pick up. I want to confirm my thinking was wrong, that all the logic should be in this block from start to completion of the operation, and it's fine even if the app stays in the foreground the whole time. 2 Then you'd create a BGContinuedProcessingTaskRequest and set request.strategy = .fail for this example because you need it to start immediately per the user's explicit tap on the Start Counting button. 3 Call BGTaskScheduler.shared.submit(request). Question 2: If the submit function throws an error, should you handle it by just performing the counting operation logic (call your function without passing a task)? I understand this can happen if for some reason the system couldn't immediately run it, like if there's already too many pending task requests. Seems you should not show an error message to the user, should still perform the request and just not support background continued processing for it (and perhaps consider showing a light warning "this operation can't be continued in the background so keep the app open"). Or should you still queue it up even though the user wants to start counting now? That leads to my next question Question 3: In what scenario would you not want the operation to start immediately (the queue behavior which is the default), given the app is already in the foreground and the user requested some operation? I'm struggling to think of an example, like a button titled Compress Photos Whenever You Can, and it may start immediately or maybe it won't? While waiting for the launchHandler to be invoked, should the UI just show 0% progress or "Pending" until the system can get to this task in the queue? Struggling to understand the use cases here, why make the user wait to start processing when they might not even intend to close the app during the operation? Thanks for any insights! As an aside, a sample project with a couple use cases would have been incredibly helpful to understand how the API is expected to be used.