General: DevForums subtopic: App & System Services > Processes & Concurrency Processes & concurrency covers a number of different technologies: Background Tasks Resources Concurrency Resources — This includes Swift concurrency. Service Management Resources XPC Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

The expirationHandler on BGProcessingTask is a () -> Void closure. It provides no information about why it was called. In my testing, all of the following trigger the same handler: Time expiration Resource pressure (CPU, memory, battery) Not reporting progress User tapping "Stop" on the Live Activity There is no way for the app to tell these apart. Questions: Q1. Is there an official, complete list of all conditions that trigger expirationHandler? The documentation only mentions "time expires." Q2. What is the specific time limit before timeout? If it varies by device state, what are the conditions? Q3. A way to distinguish the reason is needed. "User stop" and "system expiration" require completely different handling. Currently this is impossible. Environment: iOS 26, physical device

The expirationHandler on BGProcessingTask is a () -> Void closure. It provides no information about why it was called. In my testing, all of the following trigger the same handler: Time expiration Resource pressure (CPU, memory, battery) Not reporting progress User tapping "Stop" on the Live Activity There is no way for the app to tell these apart. Questions: Q1. Is there an official, complete list of all conditions that trigger expirationHandler? The documentation only mentions "time expires." Q2. What is the specific time limit before timeout? If it varies by device state, what are the conditions? Q3. A way to distinguish the reason is needed. "User stop" and "system expiration" require completely different handling. Currently this is impossible. Environment: iOS 26, physical device

Hello, I am working on a cross-platform application where IPC between a LaunchDaemon and a LaunchAgent is implemented via Unix domain sockets. On macOS, the socket path length is restricted to 104 characters. What is the Apple-recommended directory for these sockets to ensure the path remains under the limit while allowing a non-sandboxed agent to communicate with a root daemon? Standard paths like $TMPDIR are often too long for this purpose. Thank you in advance!

Hello, I have an application that needs to be published to the App Store. This application consists of two processes, A and B, where B is a child process of A. I found that if process B needs to be launched as a child process of A in sandbox mode, it is necessary to set the following keys in the entitlements.plist file: <key>com.apple.security.app-sandbox</key><true/><key>com.apple.security.inherit</key><true/> However, after setting these keys, process B can no longer be launched directly. This issue is particularly prominent because process B has a window and a Dock icon — in this case, if the user pins the Dock icon, they will be unable to launch process B. Could you please advise on a solution to this problem?

Hi, I’m looking for clarification on what concurrency and consistency guarantees Apple provides when multiple targets (main app + Widget extensions) access shared storage. Specifically: 1. UserDefaults (App Group / suiteName:) • If multiple processes (app + multiple widget instances) read and write the same shared UserDefaults, what guarantees are provided? • Is access serialized internally to prevent corruption? • Are read–modify–write operations safe across processes, or can lost updates occur? 2. Core Data (shared SQLite store in App Group container) • Is it officially supported for multiple processes to open and write to the same Core Data SQLite store? • Are there recommended configurations (e.g. WAL mode) for safe multi-process access? • Is Apple’s recommendation to have a single writer process? 3. FileManager (shared container files) • If two processes write to the same file in an App Group container, what guarantees are provided by the system? • Is atomic replaceItemAt the recommended pattern for safe cross-process updates? Additionally: • Do multiple widget instances count as separate processes with respect to these guarantees? • Is there official guidance on best practices for shared persistence between app and widget extensions? I want to ensure I’m following the correct architecture and not relying on undefined behavior. Thanks.

The same code built in a regular Mac app (with UI) does get paired. The characteristic properties are [.read, .write, .notify, .notifyEncryptionRequired] The characteristic permissions are [.readEncryptionRequired, .writeEncryptionRequired] My service is primary. In the iOS app (central) I try to read the characteristic, but an error is reported: Error code: 5, Description: Authentication is insufficient.

I have migrated my code to use SMAppService but am running into trouble deleting the old SMJobBless launchd registration using launchd remove. I am invoking this from a root shell when I detect the daemon and associated plist still exist, then also deleting those files. The remove seems to work (i.e. no errors returned) but launchd list shows the service is registered, with a status code of 28 I am using the same label for SMAppService as previously and suspect this is the reason for the problem. However, I am reluctant to change the label as there will a lot of code changes to do this. If I quit my application, disable the background job in System Settings and run sudo launchd remove in the Terminal then it is removed and my application runs as expected once the background job is re-enabled. Alternatively, a reboot seems to get things going. Any suggestions on to how I could do this more effectively welcome.

I have an older project that was created before Xcode 26.2. In Xcode versions prior to 26.2, there was no Swift Compiler – Concurrency build setting. With those older versions, the following behavior occurs: a nonisolated function executes off the main thread. class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() run() } private func run() { Task { await runInMainThread() } } func runInMainThread() async { print(">>>> IN runInMainThread(), Thread.isMainThread \(Thread.isMainThread)") await runInBackgroundThread() } private nonisolated func runInBackgroundThread() async { print(">>>> IN runInBackgroundThread(), Thread.isMainThread \(Thread.isMainThread)") } } Output: >>>> IN runInMainThread(), Thread.isMainThread true >>>> IN runInBackgroundThread(), Thread.isMainThread false However, starting with Xcode 26.2, Apple introduced the Swift Compiler – Concurrency settings. When running the same code with the default configuration: Approachable Concurrency = Yes Default Actor Isolation = MainActor This is the output Output: >>>> IN runInMainThread(), Thread.isMainThread true >>>> IN runInBackgroundThread(), Thread.isMainThread true the nonisolated function now executes on the main thread. This raises the following questions: What is the correct Swift Compiler – Concurrency configuration if I want a nonisolated function to run off the main thread? Is nonisolated still an appropriate way to ensure code runs on a background thread?

I'm working on an editor for Bevy games and wanted the following workflow: Launch the game process Host a Metal view for the game's render target Use an XPC service to transfer an MTLSharedTextureHandle Keep the connection for editor/game communication and hot reload As such I created the following editor service: public let XPCEditorServiceName = "org.bevy.editor" public enum XPCEditorMessage: Codable { case ping } public enum XPCEditorReply: Codable { case pong } extension XPCListener { static let bevy = try! XPCListener(service: XPCEditorServiceName) { request in request.accept(XPCEditorService.init) } } struct XPCEditorService: XPCPeerHandler { let session: XPCSession private func handle(_ message: XPCEditorMessage) -> XPCEditorReply? { switch message { case .ping: return .pong } } func handleIncomingRequest(_ message: XPCReceivedMessage) -> (any Encodable)? { do { return handle(try message.decode()) } catch { return nil } } func handleCancellation(error: XPCRichError) { print(error) } } and I initialize it in my app's App initializer: // Launch the XPC service print(XPCListener.bevy) I wanted to test this using an executable target with the following main.swift: let session = try XPCSession(xpcService: XPCEditorServiceName) let response: XPCEditorReply = try session.sendSync(XPCEditorMessage.ping) print("Connected to editor!") The editor prints Listener<org.bevy.editor>(Active) but the game fails with Underlying connection was invalidated. Reason: Connection init failed at lookup with error 3 - No such process What am I doing wrong? PS. Would also appreciate an example of sending & rendering the MTLSharedTextureHandle both in editor & game.

macOS 26 "Tahoe" is allocating much more memory for apps than former macOS versions: A customer contacted me with my app's Thumbnail extension allocating so much memory that her 48 GB RAM Mac Mini ran into "out of application memory" state. I couldn't identify any memory leak in my extension's code nor reproduce the issue, but found the main app allocating as much as 5 times the memory compared to running on macOS 15 or lower. This productive app is explicitly using "Liquid Glass" views as well as implicitly e.g. for an inspector pane. So I created a sample app, just based on Xcode's template of a document-based app, and the issue is still showing (although less dramatically): This sample app allocates 22 MB according to Tahoe's Activity Monitor, while Sequoia only requires 16 MB: macOS 15.6.1 macOS 26.2 Is anyone experiencing similar issues? I suspect some massive leak in Tahoe's memory management, and just filed a corresponding feedback (FB21967167).

Hi, I've now identified a few areas when BGContinuedProcessingTask gets expired by the system no progress for ~30 seconds high CPU usage high temperature Some of these I can preempt and expire preemptively and handle the notification, others I cannot and just need to let the failure bubble up. When the failure does bubble up, I'd like to update the title and subtitle. I'm able to update the title, but the subtitle is fixed at "Task Failed" Is there any workaround? Or shall I file a bug here?

I’ve built an app that connects via Bluetooth to a device. The device sends up, down, left and right commands. I want to build an SDK for other third party developers to use so that whenever a third party app with the SDK opens, if we press a button on the device, my app which captures the button press should be able to forward the event to the third party app. I want to achieve this with the lowest latency possible so that I can enable a variety of use cases like simple games and interactions within other apps. What would be the best way for me to achieve this as part of my SDK and my app?

This is a successor to: https://developer.apple.com/forums/thread/814231 I went into a slightly different direction. I generated more AI slop that use NSLock. Then I had the NSLock usage changed to Mutex usage. Now it crashes with: Task 13: EXC_BREAKPOINT (code=1, subcode=0x18d29326c) On one of the mutex closures. With an extended description: warning: TypeSystemSwiftTypeRef::operator(): had to engage SwiftASTContext fallback for type $s7Combine10PublishersO21LineBreakingPublisherE11SplitAtZeroV12Subscription33_D18F5AAE73662968F407B0A79FBD1F8DLLCy_x_qd__GD I put the class, a Subscription nested in its corresponding Publisher operator, in the given file Subscription.txt

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!

Knows anyone a point in systemlog etc. To find out when and why my or other apps are terminated by os. At the moment a lot of apps inclusive my apps seems to be terminated instead set to sleep by OS if no power coord is connected There are no crashlogs recorded, Sentry or firebase don‘t report issues.

Hello, I am currently developing an iOS application using SensorKit. I encountered an issue when attempting to fetch SensorKit data in the background using background tasks (appRefresh, processing). The following error occurs: In the delegate function func sensorReader(_ reader: SRSensorReader, fetching fetchRequest: SRFetchRequest, failedWithError error: any Error) {}, I receive the error: SRErrorDataInaccessible. In code specific manner: start and handle background fetch (appRefresh) func handleAppRefreshTask(task: BGAppRefreshTask) { logger.logWithServer(level: .default, message: "background fetch start", category: String(describing: BackgroundTaskManager.self)) scheduleBackgroundFetch() let queue = OperationQueue() queue.maxConcurrentOperationCount = 1 let fetchOperation = FetchOperation() queue.addOperation(fetchOperation) task.expirationHandler = { self.logger.logWithServer(level: .error, message: "background fetch expirated", category: String(describing: BackgroundTaskManager.self)) queue.cancelAllOperations() } fetchOperation.completionBlock = { task.setTaskCompleted(success: !fetchOperation.isCancelled) } } Background fetch operation class class FetchOperation: Operation { override func main() { guard !isCancelled else { return } Task { // this function will execute fetch request for all user allowed sensorReader, 'func fetch(_ request: SRFetchRequest)' await SensorkitManager.shared.startFetchAndUpload() } } } I have the following questions: Is it possible to fetch SensorKit data in the background? If it is possible, why does the above error occur? If it is possible, could you provide the solution code and the correct workflow to avoid this error? Thank you.

I tried making a concurrency-safe data queue. It was going well, until memory check tests crashed. It's part of an unadvertised git project. Its location is: https://github.com/CTMacUser/SynchronizedQueue/commit/84a476e8f719506cbd4cc6ef513313e4e489cae3 It's the blocked-off method "`memorySafetyReferenceTypes'" in "SynchronizedQueueTests.swift." Note that the file and its tests were originally AI slop.

I am developing a remote support tool for macOS. While we have successfully implemented a Privileged Helper Tool and LaunchDaemon architecture that works within an active Aqua session, we have observed a total failure to capture the screen buffer or receive input at the macOS Login Window. Our observation of competitor software (AnyDesk, TeamViewer) shows they maintain graphical continuity through logout/restart. We are seeking the official architectural path to replicate this system-level access. Current Technical Implementation Architecture: A root-level LaunchDaemon manages the persistent network connection. A PrivilegedHelperTool (installed in /Library/PrivilegedHelperTools/) is used for elevated tasks. Environment: Tested on macOS 14.x (Sonoma) and macOS 15.x (Sequoia) on Apple Silicon. Capture Methods: We have implemented ScreenCaptureKit (SCK) as the primary engine and CGDisplayCreateImage as a fallback. Binary Status: All components are signed with a Developer ID and have been successfully Notarized. Observed Behavior & Blockers The "Aqua" Success: Within a logged-in user session, our CGI correctly identifies Display IDs and initializes the capture stream. Remote control is fully functional. The "Pre-Login" Failure: When the Mac is at the Login Window (no user logged in), the following occurs: The Daemon remains active, but the screen capture buffer returns NULL or an empty frame. ScreenCaptureKit fails to initialize, citing a lack of graphical context. No TCC (Transparency, Consent, and Control) prompt can appear because no user session exists. The "Bootstrap" Observation: We have identified that the loginwindow process exists in a restricted Mach bootstrap namespace that our Daemon (running in the System domain) cannot natively bridge. Comparative Analysis (Competitor Benchmarking) We have analyzed established remote desktop solutions like AnyDesk and Jump Desktop to understand their success at the login screen. Our findings suggest: Dual-Context Execution: They appear to use a Global LaunchAgent with LimitLoadToSessionType = ["LoginWindow"]. This allows a child process to run as root inside the login window’s graphical domain. Specialized Entitlements: These apps have migrated to the com.apple.developer.persistent-content-capture entitlement. This restricted capability allows them to bypass the weekly/monthly TCC re-authorization prompts and function in unattended scenarios where a user cannot click "Allow." Questions Entitlement Requirement: Is the persistent-content-capture entitlement the only supported way for a third-party app to capture the LoginWindow buffer without manual user intervention? LaunchAgent Strategy: To gain a graphical context at the login screen, is it recommended to load a specialized agent into the loginwindow domain via launchctl bootstrap loginwindow ...? ScreenCaptureKit vs. Legacy: Does ScreenCaptureKit officially support the LoginWindow session, or does it require an active Aqua session to initialize? MDM Bypass: For Enterprise environments, can a Privacy Preferences Policy Control (PPPC) payload grant "Screen Recording" to a non-entitled Daemon specifically for the login window context?

I'm specifically focused on Live Activity, but I think this is somewhat a general question. The app could get a few callbacks when: There's a new payload (start, update, end) There's a new token (start, update) There's some other lifecycle event (stale, dismissed) Assuming that the user didn't force kill the app, would the app get launched in all these scenarios? When OS launches the app for a reason, should we wrap our tasks with beginBackgroundTask or that's unnecessary if we're expecting our tasks to finish within 30 seconds? Or the OS may sometimes be under stress and give you far less time (example 3 seconds) and if you're in slow internet, then adding beginBackgroundTask may actually come in handy?

Let's image that someone wants to use a background service to keep track of FSEvents activity, at the file level (a firehose, some might say). I choose this example, to indicate the volume and rate of data transmission in question. I'm not creating a front-end for FSEvents data, but my background service may generate data at a similar pace. The service runs off of user defined document/s that specify the FSEvent background filtering to be applied. Those that match get stored into a database. But filters can match on almost all the data being emitted by FSEvents. The user decides to check on the service's activity and database writes by launching a GUI that sends requests to the background service using XPC. So the GUI can request historic data from a database, but also get a real-time view of what FS events the service is busy filtering. So it's a client-server approach, that's concerned with monitoring an event stream over XPC. I understand XPC is a request/response mechanism, and I might look into using a reverse connection here, but my main concern is one of performance. Is XPC capable of coping with such a high volume of data transmision? Could it cope with 1000s of rows of table data updates per second sent to a GUI frontend? I know there are streaming protocol options that involve a TCP connection, but I really want to stay away from opening sockets.