Hello, appreciate any help here. Objective: perform a scoped write to a removable block device (using low-level system frameworks in C). Issue: launchd-run privileged helper (as root) denied permission to open block device. Manual 'sudo ./helper' call succeeds, however. Importantly: the entire process works flawlessly if the main app is granted Full Disk Access in Privacy & Security. However, this should be completely unnecessary for this objective, as scoped access should be sufficient, and FDA is in fact not required for other apps which perform this task. Architecture and flow: Main GUI process collects ISO path and target removable device path (queried via IOKit). Main GUI process installs a Privileged Helper via SMJobBless. The Privileged Helper is started on demand by launchd as root (UID 0, EUID 0). Main GUI process communicates selected ISO and device paths to Privileged Helper via XPC. Privileged Helper conducts security and sanity checks, unmounts volumes from target device via DiskArbitration. Privileged Helper obtains file handles to ISO and target block device (e.g.: "/dev/disk4"). Privileged Helper performs a byte-by-byte write to the target block device. Problematic area: Simplified example using C syscalls (via Zig): const path = "/dev/disk5"; // Note that even with readonly flag this fails const fd = c.open(path, c.O_RDONLY, @as(c_uint, 0)); defer _ = c.close(fd); if (fd < 0) { const err_num = c.__error().*; const err_str = c.strerror(err_num); log("open() failed with errno {}: {s}", .{ err_num, err_str }); } Output (when run by launchd - UID 0, EUID 0, domain: system): open() failed with errno 1: Operation not permitted Simplified example with Zig open interface: const directory = try std.fs.openDirAbsolute(deviceDir, .{ .no_follow = true }); const device = try directory.openFile("/dev/disk5", .{ .mode = .read_write, .lock = .exclusive }); errdefer device.close(); Output (when run by launchd - UID 0, EUID 0, domain: system): Error: error.AccessDenied Running the same examples by manually launching the binary with a test argument succeeds: sudo ./helper "/dev/disk5" ... Notable points: Both Main GUI process and the Privileged Helper binary are codesigned (via codesign ...). Privileged Helper has both Info.plist and Launchd.plist symbols exported into its binary. Privileged Helper has no codesign flags (e.g.: for hardened runtime or others): CodeDirectory v=20400 size=8130 flags=0x0(none) hashes=248+2 location=embedded Output of sudo launchctl print system/<helper-bundle-id> shows nothing of interest to indicate any security restrictions. Appreciate any advice here!

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!

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?

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?

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.

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

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

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?

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?

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!

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?

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!

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!

Hell Apple Developer Community, I need help with the Upload of my Project to AppStore Connect. I’ve got an Error Message, that tells me something is missing in the Info.plist file. Can somebody help me?

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.

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

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.