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"

We are evaluating a lifecycle architecture for a local macOS application and would appreciate guidance on supported public APIs. Proposed architecture: A normally signed, non-root host application. One embedded XPC service with exactly one intended client. No application-created subprocesses inside the service. No privileged helper, persistent LaunchAgent, exported endpoints, private APIs, or reduced system security. One bounded operation per session. Failed or interrupted operations must not automatically be retried. Initial validation would use synthetic workloads only. Our current evaluation target is macOS 15.6 on Apple silicon, using the macOS 15.5 SDK. Please identify any relevant deployment-version limitations. The XPC overview (https://developer.apple.com/documentation/xpc) describes an embedded service as tied to its client's lifetime. We also understand that xpc_connection_cancel (https://developer.apple.com/documentation/xpc/xpc_connection_cancel(_:)) is asynchronous and non-preemptive; we are not treating connection cancellation as proof of service termination. We need clarification on these points: Client death and service startup Does the documented client-lifetime relationship cover client termination, including SIGKILL, during service startup before the first reply? Does it also cover an already running service that is blocked or stopped with SIGSTOP? Which behavior is guaranteed, and which timing or failure cases are intentionally unspecified? Timeout while the client remains alive What supported public mechanism should a normal application use to terminate its own unresponsive embedded service when an operation exceeds its deadline? We want to avoid PID enumeration, PID-reuse races, broad process-group signaling, and exporting a full task-control port. Is there a supported identity-bound termination mechanism? If not, what architecture does Apple recommend? A stopped or hung client remains alive, so we do not assume client-lifetime coupling handles that separate failure case. Observing termination Which public notification reliably identifies the exit of the particular service instance, as distinct from connection invalidation or a missing reply? Because launchd is the parent, the application cannot simply waitpid the service. Is reaping entirely launchd's responsibility, and what completion claim can the application legitimately make? Identity and required privileges Which public signing requirements, launch constraints, sandbox settings, or entitlements are necessary for this architecture? Please distinguish authentication before accepting work from constraints enforced before service code executes. We do not assume peer authentication also grants termination rights. Restart behavior After interruption, cancellation, client exit, or service failure, under what circumstances can launchd or subsequent XPC activity start a replacement service? What supported pattern prevents accidental resubmission or resumption of the same failed operation? We are not asking for hard real-time guarantees during kernel failure, or claiming that forced termination proves callback completion or explicit memory zeroization. If this combination of requirements is unsupported, identifying that boundary and the smallest supported architectural alternative would be a useful answer. Documentation references or a minimal public sample would be welcome.

I am designing a bounded local diagnostic helper for macOS. It would run only purpose-built helpers supplied by the application, not third-party or untrusted code. The design question is how to stop exactly those helpers and their descendants on timeout, without affecting an unrelated process or incorrectly reporting that cleanup is complete. This is a public-API suitability question, not a report of a reproduced macOS bug. The intended diagnostic is not an antivirus or endpoint-detection product. The required properties are: Identify each owned process by its lifetime and association with this helper run, not a numeric PID or process-group ID alone. Account for descendants across fork/exec, parent exit or reparenting, and process-group/session changes. Observing that a descendant escaped is not equivalent to preventing an escape. Terminate only the still-owned processes without a stale-identity race between checking ownership and signaling. Report completion only when all owned descendants have stopped and no new owned descendants can appear. Leader exit, IPC disconnection, or an unauthenticated empty process list would not be sufficient. Lost events or uncertain membership must leave the outcome inconclusive. Which supported public API or service/containment architecture can provide these properties? If they cannot all be guaranteed, which constraint should be changed and what guarantee can the supported alternative actually provide? I have reviewed the documentation for es_new_descendants_client and es_sync_client. The remaining questions are: Is a descendant-scoped Endpoint Security client appropriate for this non-security-product diagnostic? If so, which documented entitlement and packaging route applies? I am asking about eligibility, not assuming it. Does any supported design combine lifetime-safe control with containment of the whole owned subtree, including concurrent descendant creation? Merely receiving events would not establish that property. What additional protocol, if any, makes a synchronization callback sufficient to establish complete termination when client destruction, event loss, and concurrent activity are possible? I am not treating that callback alone as proof that no owned process remains. I can redesign around a helper that cannot create descendants if that is the supported approach. In that case, what supported mechanism enforces that restriction and what termination guarantees remain? So far, a standalone C harness has passed eleven fabricated-input cases with assertions enabled. It exercised no Endpoint Security client, process-tree creation/enumeration/control, or application behavior. It is not a runtime reproducer for this API-design question and does not establish native lifecycle safety. Pointers to documented guarantees, limitations, or an Apple sample would help me choose the architecture before preparing a narrowly scoped native test. I am not seeking private APIs or a way to disable platform protections. No logs, source archive, or binary is attached.

My macOS app Find Any File contains another app inside its Resources folder. It's a background-only app that checks if the user presses a hotkey, in which case it launches my app. Since macOS 27, when the hotkey app is running, it appears in the Dock with a "Running in Background" subtitle. That's totally not wanted. How do I make it not appear in the Dock? I've got both "LSBackgroundOnly" and "LSUIElement" set to true in the Info.plist, to no avail.

I develop a tool on macOS which is composed of an UI app to manage the main app settings, and an Agent that runs in background doing some tasks ? (Running the agent is optional, can be launched from the UI app, and can be launched by macOS at startup with SMAppService. ) Agent has the LSUIElement flag set, and only shows a Menu Extra (or whatever it now named), and sometimes some notifications. The whole App package is bundled this way MainAppUI.app/Contents/Library/LoginItems/AppAgent.app (for SMAppService to work) This has been working correctly for years Now on macOS 27 beta, once I quit the UI App, having launched the Agent, the Dock reports the UI App is still running in background (with the grey dot) . But only the Agent is running, not the UI app process. Moreover, System Settings->Background apps reports both the UI app AND the Agent as both requesting to run in background. I would have expected only the Agent being listed in System Settings, and nothing appearing in the Dock. Is this a bug in the OS beta , showing the top-level container bundle as the app running in background instead of the executable direct container ? Or maybe it's on me and I should bundle my app differently ? (I cannot "reverse" the bundle and put the Agent as the main app, with UI "inside", as double clicking the main app should launch the UI App , not the Agent. ) BTW, filed FB23203848 for the same subject. thanks for any direction

Hello, we have encountered a large number of __CFRunLoopServiceMachPort.cold crashes on iOS 26. These crashes frequently occur when the app transitions from the background to the foreground or is launched after sitting idle for a period of time. Despite extensive analysis, we have been unable to find a solution. Currently, the crash data indicates that this issue is specific to iOS 26. We would greatly appreciate your assistance. Thank you very much! Hardware Model: iPhone18,1 OS Version: iPhone OS 26.5.2 (23F84) Release Type: User Baseband Version: 1.60.02 Crash Reporter Key: fda96a4036dcb83e124660e11b654c9484b81dae Incident Identifier: EF18C4DD-7624-42D0-BA72-F17BBC263B16 Time Awake Since Boot: 2900000 seconds Triggered by Thread: 0, Dispatch Queue: com.apple.main-thread Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x00000001917d316c Termination Reason: Namespace SIGNAL, Code 5, Trace/BPT trap: 5 Terminating Process: exc handler [82210] Application Specific Information: (ipc/rcv) invalid name Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 CoreFoundation 0x1917d316c __CFRunLoopServiceMachPort.cold.1 + 64 1 CoreFoundation 0x19168a444 __CFRunLoopServiceMachPort + 416 2 CoreFoundation 0x191654310 __CFRunLoopRun + 1188 3 CoreFoundation 0x19165354c _CFRunLoopRunSpecificWithOptions + 532 4 GraphicsServices 0x236df7498 GSEventRunModal + 120 5 UIKitCore 0x19734c244 -[UIApplication _run] + 796 6 UIKitCore 0x1972b7158 UIApplicationMain + 332 7 KMMVideo 0x1047fe24c 0x104304000 + 5218892 8 dyld 0x18e261c1c start + 6928 Thread 1 name: transmit_hls_7683_193735 Thread 1: 0 libsystem_kernel.dylib 0x2407da5e8 __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x1f0852b48 _pthread_cond_wait + 980 2 libc++.1.dylib 0x1a0d5dbcc std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 32 3 iOSPlayer 0x118cd6114 a_task_runner::worker() + 116 4 iOSPlayer 0x118cd5650 a_task_runner::work_thread() + 196 5 iOSPlayer 0x118cd654c void* std::__1::__thread_proxy[abi:ne200100]<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_deletestd::__1::__thread_struct>, void (a_task_runner::)(), a_task_runner>>(void*) + 72 6 libsystem_pthread.dylib 0x1f0854438 _pthread_start + 136 7 libsystem_pthread.dylib 0x1f08508cc thread_start + 8 Thread 2: 0 libsystem_kernel.dylib 0x2407d9ed8 read + 8 1 XLTranscodeKit 0x115bb5f4c runtime.read_trampoline.abi0 + 28 Thread 3: Thread 4: 0 libsystem_kernel.dylib 0x2407da5e8 __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x1f0852b48 _pthread_cond_wait + 980 2 XLTranscodeKit 0x115bb6648 runtime.pthread_cond_wait_trampoline.abi0 + 24 3 XLTranscodeKit 0x115bb4fb8 runtime.asmcgocall.abi0 + 200 4 ??? 0xd65f03c0 ??? Thread 5: 0 XLTranscodeKit 0x115b3eb68 */bytealg.IndexByteString + 40 1 XLTranscodeKit 0x115b966b8 runtime.findnull + 104 Thread 6: 0 libsystem_kernel.dylib 0x2407db8dc kevent + 8 1 XLTranscodeKit 0x115bb6398 runtime.kevent_trampoline.abi0 + 40 Thread 7: 0 libsystem_kernel.dylib 0x2407da5e8 __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x1f0852b48 _pthread_cond_wait + 980 2 XLTranscodeKit 0x115bb6648 runtime.pthread_cond_wait_trampoline.abi0 + 24 3 XLTranscodeKit 0x115bb4fb8 runtime.asmcgocall.abi0 + 200 4 ??? 0xd65f03c0 ???

It is possible for an extension to an app (based on ExtensionFoundation) to declare its own extension point and host its own ExtensionFoundation extensions? Based on the documentation, I am guessing the answer is no, but worth double-checking. What would be the reason to prevent this? Every ExtensionFoundation extension runs in its own process, and may have need to be extended safely just as its host app does. Thank you!

I’m designing a macOS privileged-service boundary and I’d like to clarify whether a process-occurrence authentication pattern previously described by Apple DTS is a supported shipping security contract, rather than just behaviour that happens to work on current macOS. Target: current macOS 26.x, using public APIs only. Threat model An arbitrary hostile process may run as the same ordinary, non-admin login user as the application. The attacker can launch an exact second copy of the legitimately signed requester binary. The attacker cannot obtain administrator / Touch ID authorization and does not control root, SIP, Recovery, the kernel, or the code-signing infrastructure. Desired property After a fresh Human-authorized operation, a root LaunchDaemon should grant authority to one specific requester process occurrence, not to every process having the same code-signing identity. Apple DTS thread 842442 describes a pattern based on: launching the requester suspended with posix_spawn(..., POSIX_SPAWN_START_SUSPENDED); obtaining a name/task port for that process; reading its TASK_AUDIT_TOKEN; resuming the process; and accepting only Mach messages whose kernel audit trailer identifies that same process occurrence. Thread 842442 also describes this area as being on “thin compatibility ice”, which is why I do not want to build a security boundary on behaviour that Apple does not intend applications to rely on. My core question is: Can a shipping macOS application rely on a pre-bound audit_token_t obtained from a suspended child and compare it against the audit token in subsequent raw Mach message trailers as a supported security boundary for that exact process occurrence? In particular, I need to know whether the supported contract covers: distinguishing another process with the exact same signed executable; PID reuse after the original process exits; messages queued before or around sender termination; a Mach send right transferred to another process — does the receiver see the audit token of the process that actually sends each message?; later exec by the original process; and whether full audit_token_t equality is an appropriate supported comparison for this purpose. If that is not a supported shipping contract, is there a current public XPC API that provides the equivalent property: binding one privileged-service session to one exact process occurrence rather than merely to its code-signing identity? I’m specifically trying to distinguish: code identity = this is an approved executable from mission authority = this one particular authorized process occurrence I’m happy with a negative answer if macOS does not expose a stable public contract for the latter. Related Apple DTS discussion: https://developer.apple.com/forums/thread/842442

I’m designing a macOS utility that needs to run a bounded, one-shot diagnostic and collect its result. The lifetime problem is: A controller asks for the diagnostic to start. The diagnostic may begin successfully. The controller can then fail immediately — potentially before it has retained the child’s PID or established output collection. The diagnostic may close stdin/stdout/stderr while continuing to run. The diagnostic must not become an unmanaged orphan if the controller disappears. A focused test case uses Foundation.Process: Controller launches Child. Controller immediately exits with _exit(42), without waiting for Child or retaining its process identifier. Child calls setsid(), closes stdin/stdout/stderr, stays alive for up to 120 seconds, then exits. What I’m trying to establish is the supported macOS lifecycle boundary, rather than inventing a cleanup scheme around PIDs. Is there a supported per-user launchd or other OS-managed mechanism where the OS assumes responsibility for the job before the diagnostic process can start, such that the requesting controller may subsequently fail without leaving an unmanaged process? Specifically: At what point does the OS own the lifetime relative to registration and process creation? What supported mechanism bounds or terminates the job if the requesting controller disappears? Is there a supported hard execution-time limit, rather than an idle-time concept? How are descendants or process groups contained, and does calling setsid() conflict with that containment? What completion or failure information remains available to a later controller after the original requester has died? Are there important per-user, privilege, sandboxing, signing, or macOS-version limitations? I’m not reporting an Apple bug and I’m not asking for a custom recovery implementation. I’m trying to identify the documented supported lifetime mechanism and its guarantees and limitations before choosing an architecture. Environment: macOS 26.6.2 Apple silicon Foundation.Process is used by the focused reproducer Apple Developer Technical Support suggested I start a new thread for this specific question in Processes & Concurrency.

Deployment scope: macOS 26 and macOS 27, Apple silicon / arm64 only. Intel / x86_64 and Rosetta behavior are outside this inquiry. Please distinguish applicability and limitations for each named macOS version; support for one version must not be assumed to establish support for the other. We are evaluating a directly created child's lifecycle in a continuously living original parent, using documented posix_spawn, kill and wait interfaces. This is a support-contract clarification, not a report of a reproduced OS defect. We have not conducted a process experiment. The proposed parent would serialize every action against every potentially consuming wait, exclude competing waiters, retain SIGCHLD status (no SA_NOCLDWAIT or explicit SIG_IGN), and permanently revoke further actions before permitting final reap. Parent loss or uncertain ownership causes refusal, with no adoption or respawn. We are not asking for private interfaces or implementation internals. POSIX.1-2024 XBD 4.17 prohibits PID reuse before process lifetime ends. Its _exit description connects normal zombie lifetime to collection of status, with explicit automatic-disposal exceptions. We recognize that UNIX 03 certification is a different edition/profile and do not assume POSIX.1-2024 applicability to macOS. For the specified deployment range, please identify the applicable supported documentation/standard profile and clarify: Under the stated exclusions, is a directly created child's positive PID reserved against reassignment through exit/zombie state until a defined consuming wait boundary? Which documented exceptions or ownership transitions defeat that premise? What is the supported consuming boundary for wait/waitpid, including WNOHANG, EINTR, stopped status and concurrent waiters? Does excluding all consuming waits during an action close the numeric-replacement risk, or is another supported condition required? Please identify the documented effects of explicit SIG_IGN versus SIG_DFL, SA_NOCLDWAIT, exec and parent death that are relevant to that exact reservation claim. We do not infer unchanged executable identity, permissions or successful termination from unchanged PID. We are asking for version-applicable supported semantics, including any limits on the conclusion, rather than empirical plausibility or absence of a known counterexample. If this guarantee is not supported, please say so. We are not asking you to certify our implementation, cleanup of descendants, or full supervisor correctness. Primary references: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html https://pubs.opengroup.org/onlinepubs/9799919799/functions/_exit.html https://www.opengroup.org/openbrand/register/apple.htm

hello, i have an issue spawning continued background processing tasks: they are never started, even after restarting the device, regardless of which app spawns a task. deleting and reinstalling an app, or installing a new app that didn't exist before also does not work. it can be reproduced by setting your device local time to one year in advance and then trying to spawn the task. the task will not start and even after returning to the proper date, all apps on the device are still unable to spawn any. i also believe there are other things that trigger this issue (or something related), as many of my users have complained about tasks not starting. prior to my changing the date of my device, they worked perfectly for me. one user changed their date to test at the same time as me and the only fix they found was erasing their device and restoring a backup. on ios 26 tasks fail silently, but on ios 27 with the new api to submit a task, an error is caught: Error Domain=BGTaskSchedulerErrorDomain Code=1 "connection to service with pid 94 named com.apple.duetactivityscheduler" UserInfo={NSDebugDescription=connection to service with pid 94 named com.apple.duetactivityscheduler} in addition, a more detailed error with a stack trace is logged at the same time: <NSXPCConnection: 0x10c60c0a0> connection to service with pid 94 named com.apple.duetactivityscheduler: Exception caught during decoding of reply to message 'submitTaskRequest:withHandler:', dropping incoming message and calling failure block. Ignored Exception: Exception while decoding argument 0 (#1 of invocation): <NSInvocation: 0x10c6d72c0> return value: {v} void target: {@?} 0x0 (block) argument 1: {@} 0x0 Exception: value for key 'NS.objects' was of unexpected class 'NSSet' (0x20620c358) [/System/Library/Frameworks/CoreFoundation.framework]. Allowed classes are: {( "'NSDate' (0x20620c268) [/System/Library/Frameworks/CoreFoundation.framework]", "'NSError' (0x2061fd3b0) [/System/Library/Frameworks/Foundation.framework]", "'NSNumber' (0x2061fd478) [/System/Library/Frameworks/Foundation.framework]", "'NSData' (0x20620c650) [/System/Library/Frameworks/CoreFoundation.framework]", "'NSArray' (0x20620c6c8) [/System/Library/Frameworks/CoreFoundation.framework]", "'NSString' (0x2061fd428) [/System/Library/Frameworks/Foundation.framework]", "'NSDictionary' (0x20620c538) [/System/Library/Frameworks/CoreFoundation.framework]", "'NSURL' (0x20620c678) [/System/Library/Frameworks/CoreFoundation.framework]" )} ( 0 CoreFoundation 0x000000019fbc2e0c 43092235-E272-3CAF-B9AE-76669EC5AE46 + 622092 1 libobjc.A.dylib 0x000000019f940298 objc_exception_throw + 88 2 Foundation 0x00000001a002beac E642F95D-61DA-3E8C-A2D2-CFEB7F7B688B + 126636 3 Foundation 0x00000001a0035090 E642F95D-61DA-3E8C-A2D2-CFEB7F7B688B + 163984 ...

Summary: Starting from iPadOS 26.4, the maximum memory available to a single app has been reduced from approximately 6GB to 3GB on an 8GB iPad. This change persists in iPadOS 26.5 and has not been addressed. This breaks core functionality of memory-intensive applications such as 3D scanning apps that require large amounts of RAM to process models. Device: iPad with 8GB RAM Affected versions: iPadOS 26.4, iPadOS 26.5 Working version: iPadOS 26.0 / 26.1 / 26.2 / 26.3 Measured Data: iPadOS 26.0–26.3: App available memory ≈ 6GB (75% of total RAM) iPadOS 26.4–26.5: App available memory ≈ 3GB (37.5% of total RAM) Measurement method: Apple system API Impact: This is a regression, not expected behavior. The available memory per app has been cut by 50% without any official documentation or release notes mentioning this change. As a result, our 3D scanning application crashes immediately when attempting to process 3D models on iPadOS 26.4 and later. The app requires substantial RAM to load and process 3D model data. With only 3GB available, memory allocation fails during model processing, causing the app to crash (EXC_RESOURCE / OOM kill). This core functionality was working correctly on iPadOS 26.3 and earlier with the same device and same app binary. This regression makes our app's primary feature completely unusable for all users on iPadOS 26.4+. Steps to Reproduce: On an 8GB iPad, install iPadOS 26.0 Measure available app memory using Apple system API Upgrade to iPadOS 26.4 or 26.5 Measure available app memory again Observe: available memory drops from ~6GB to ~3GB Expected Result: Available memory per app should remain consistent across minor OS updates, or any changes should be documented. Actual Result: Available memory per app dropped by 50% starting in iPadOS 26.4, with no documentation of this change. Additional Notes: Disabling Apple Intelligence does not resolve the issue This issue was not fixed in iPadOS 26.5 Other developers have reported increased crash rates starting in iPadOS 26.4 (Apple Developer Forums)

In transitioning an existing privileged helper tool from SMJobBless to the new-ish SMAppService APIs, I ran into a problem. Registration via [SMAppService daemonServiceWithPlistName:...]; works and I get the green light via SMAppServiceStatusEnabled. Presumably that means my app’s bundle structure is correct, except that when my app creates a connection to the named mach service advertised by the helper tool, the helper tool process no longer launches on-demand. The client side (main app) uses: xpc_connection_create_mach_service("com.fxfactory.FxFactory.helper", queue, XPC_CONNECTION_MACH_SERVICE_PRIVILEGED); The listener / helper tool uses: xpc_connection_create_mach_service("com.fxfactory.FxFactory.helper", dispatch_get_main_queue(), XPC_CONNECTION_MACH_SERVICE_LISTENER); When installed via SMJobBless, the privileged helper tool would automatically launch when a connection attempt is made by the app. This no longer works. The app sits indefinitely, never receiving a reply on its otherwise "live" xpc_connection. The only useful hints on the Console seemed to be the following: taskgated-helper Checking profile: FxFactory Provisioning Profile 2026-1-15 taskgated-helper com.fxfactory.FxFactory.helper: Unsatisfied entitlements: com.apple.developer.service-management.managed-by-main-app taskgated-helper Disallowing: com.fxfactory.FxFactory.helper ...and: /Applications/FxFactory.app/Contents/MacOS/com.fxfactory.FxFactory.helper not valid: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=file:///Applications/FxFactory.app/Contents/MacOS/com.fxfactory.FxFactory.helper, unsatisfiedEntitlements=<CFArray 0x7b94c33a40 [0x200d1aab0]>{type = immutable, count = 1, values = ( 0 : <CFString 0x7b950305a0 [0x200d1aab0]>{contents = "com.apple.developer.service-management.managed-by-main-app"} )}, NSLocalizedDescription=No matching profile found} I'm testing this on macOS 27 Beta, not sure if that would/should make a difference. LLMs give a ton of contradicting advice on this topic. I would be great to clear some things out: In addition to having the launchd plist that describes the helper tool copied to /Contents/Library/LaunchDaemons, should the same plist also be embedded by the helper tool binary via -sectcreate __TEXT __launchd_plist? Is it true that XPC_CONNECTION_MACH_SERVICE_PRIVILEGED should be omitted from the client, when using the new SMAppService API? (the LLM surely insisted on this point, but passing 0 didn't fix anything.) What are the unsatisfied requirements of the com.apple.developer.service-management.managed-by-main-app that taskgated is referring to? Again LLMs insist that there are no additional requirements beyond code-signing by the same team, but this must be false. Could it be that helper tool needs to use the same provisioning profile as the main app? Could it be that it needs its own, tied to its own bundle ID? Here are the entitlements on the helper tool sitting in the /Contents/MacOS/ directory of the app bundle, presumably the result of the build process injecting them into their own __TEXT section, similarly to how one would inject __launchd_plist: [Dict] [Key] com.apple.developer.service-management.managed-by-main-app [Value] [Bool] true [Key] com.apple.security.app-sandbox [Value] [Bool] false [Key] com.apple.security.get-task-allow [Value] [Bool] true Assuming that my privileged helper tool is not launching simply because my bundle is violating the requirements for the com.apple.developer.service-management.managed-by-main-app entitlement, what exactly are these requirements? As a side question: if one needs these LaunchDaemons to perform some actions with root privileges, what exactly would enabling the App Sandbox (com.apple.security.app-sandbox = true) on the privileged helper tool accomplish? Is there any point in confining a process with root privileges inside a container? Thank you!

Swift Concurrency Resources: Forums tags: Concurrency The Swift Programming Language > Concurrency documentation Migrating to Swift 6 documentation WWDC 2022 Session 110351 Eliminate data races using Swift Concurrency — This ‘sailing on the sea of concurrency’ talk is a great introduction to the fundamentals. WWDC 2021 Session 10134 Explore structured concurrency in Swift — The table that starts rolling out at around 25:45 is really helpful. Swift Async Algorithms package Swift Concurrency Proposal Index DevForum post Swift Concurrency template in Instruments — To get started with this, watch WWDC 2022 Session 110350 Visualize and optimize Swift concurrency. See the Xcode 27 Release Notes for information about recent changes. LLDB’s language swift task command swift inspect dump-concurrency command — See this thread on Swift Forums. Why is flow control important? forums post Dispatch Resources: Forums tags: Dispatch Dispatch documentation — Note that the Swift API and C API, while generally aligned, are different in many details. Make sure you select the right language at the top of the page. Dispatch man pages — While the standard Dispatch documentation is good, you can still find some great tidbits in the man pages. See Reading UNIX Manual Pages. Start by reading dispatch in section 3. WWDC 2015 Session 718 Building Responsive and Efficient Apps with GCD [1] WWDC 2017 Session 706 Modernizing Grand Central Dispatch Usage [1] Avoid Dispatch Global Concurrent Queues forums post Waiting for an Async Result in a Synchronous Function forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] These videos may or may not be available from Apple. If not, the URL should help you locate other sources of this info.

I’m looking for clarification on supported public API semantics on macOS. Target runtime: arm64 macOS 15.4.1 build 24E263 The question is whether macOS provides a supported public API, or a supported composition of public APIs, that allows an external launcher or OS observer to: Obtain and freeze an identifier I(P) for the exact post-exec occurrence of a process P before P sends a security-sensitive IPC request. Later obtain OS-supplied sender identity J(M) for an individual XPC or raw Mach message M. Determine, using documented comparison semantics, whether J(M) identifies the same process-image occurrence as I(P). The comparison needs to distinguish cases such as: two concurrent processes with the same UID and signed code; exec replacement while retaining a PID; exit, restart, and PID reuse; stale or queued messages; a transferred XPC endpoint or Mach send right; an undelegated proxy. PID, UID, code-signing identity, launch labels, connection/right possession, or “first message wins” are not sufficient by themselves for this requirement. I have looked at mechanisms including: suspended process launch; task identity tokens; Endpoint Security AUTH_EXEC process identity; XPC per-message sender identity; SecCodeCreateWithXPCMessage; Mach audit trailers. What I have not found is public documentation defining a common process-occurrence identity and a supported comparison procedure across the pre-IPC and later message-sender surfaces. A token generated by the target and sent in its first message also would not solve this specific problem, because the process claiming the token has already selected itself before the external observer binds the expected occurrence. Is there a supported public way to achieve this? If so, I would appreciate pointers to: the relevant public APIs; the canonical comparison procedure; required entitlements, task rights, TCC permissions, root privileges, or system-extension requirements; documented behavior across exec, exit, restart, and PID reuse; relevant Apple documentation or sample code. If there is no supported public API that provides this property, confirmation of that would also be very helpful. I’m specifically interested in documented, supported public API semantics rather than private SPI or undocumented implementation behavior.

I’m building an app that contributes to a crowdsourced earthquake early warning network: the device reports anomalous accelerometer readings, a server correlates them across nearby devices, and users farther from the epicenter get a warning seconds ahead. Detection has to continue while the app isn’t in the foreground. I’ve ruled out the obvious paths — CMMotionManager stops on suspension, CMPedometer and CMMotionActivityManager only return historical data, BGTaskScheduler is too infrequent, and CMSensorRecorder is watchOS-only. I’ve also read thread 765258, where DTS confirmed there’s no background capability for accelerometer data and that repurposing another one risks rejection under 2.5.4, so I’m not looking for a workaround. Is there any supported way to do this on iOS, for instance restricted to when the device is stationary and charging? Or is this outside what the platform currently allows? Thanks.

I'm working on an iPhone app that continuously monitors device tilt with Core Motion. When the device has been held tilted forward past a threshold angle for a sustained period, the app raises a local notification. The detection has to keep running while my app is in the background. The situation I need to detect is, by definition, one where the user is looking at some other app — if my app were in the foreground, there would be nothing to detect. So a foreground-only implementation would not implement the feature at all. While testing this I ran into a behavior I would like to understand properly before I rely on it. What I observe CMMotionManager device-motion updates to a backgrounded app stop within a few seconds of the app leaving the foreground — unless a Core Location session is running at the same time. With location updates started under When In Use authorization and allowsBackgroundLocationUpdates = true, the device-motion callbacks continue for the whole time the app is backgrounded. Stop the location session, and they stop again. I built a focused sample to measure this. It starts device-motion updates at 10 Hz on a background OperationQueue and counts every callback, records the count on didEnterBackground, and on willEnterForeground logs how many arrived during the interval against how many would be expected at 10 Hz. Measured on an iPhone running iOS 26.5.2, launched from the Home screen with no debugger attached: location ON | background 137s | received 1366 / expected ~1373 (99.5%) location OFF | background 129s | received 2 / expected ~1286 (0.16%) Both callbacks in the second run arrived immediately after the transition to the background; nothing arrived over the remaining two minutes. One thing that cost me a test cycle, in case it saves someone else one: the difference only shows up when the app is launched from the Home screen. With the Xcode debugger attached the app is not suspended, and both cases deliver callbacks for the entire interval. The location session in the sample is configured as low as I can make it, since the app never reads the coordinates: manager.desiredAccuracy = kCLLocationAccuracyThreeKilometers manager.distanceFilter = 3000 manager.activityType = .other manager.pausesLocationUpdatesAutomatically = false manager.requestWhenInUseAuthorization() // started from the foreground, once authorization is granted manager.allowsBackgroundLocationUpdates = true manager.startUpdatingLocation() func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) { // Intentionally empty. This sample does not use the location values. } My questions Is continuous CMDeviceMotion delivery to a backgrounded app dependent on an active Core Location session? Is that intended and expected behavior on current iOS versions, or an implementation detail I should not be relying on? If it is expected behavior, what configuration would you recommend for an app in this situation? Specifically, is kCLLocationAccuracyThreeKilometers with a large distanceFilter sufficient to sustain the session, or does reliable delivery require a higher accuracy or a smaller distance filter? Is there another supported API or background execution mechanism that delivers continuous device-motion or accelerometer data to a backgrounded app? I am aware of CMSensorRecorder for retrospective retrieval, but I need to react in near real time. I would like to be sure I am not overlooking a more appropriate API. Environment: iOS 18.0 and later, iPhone only, Swift / SwiftUI. I have the focused sample project available if it would be useful. Thanks very much for any help.

So recently I migrated the topshelf extension for my app from the deprecated TVServiceProvider to the new TVContentProvider in 13.0 and onwards.I finally got it working (not helped by wasting hours figuring out that the NSExtensionPrincipalClass has to be the first thing listed in the NSExtension dictionary in the Info.plist or the extension just terminates, I kid you not!) but there is one last thing that I can't figure out.What works:1. remove any instance of my application from the Apple TV2. install and launch my app from xcode on the Apple TV3. when i back out of the app, the topshelf code is working, it calls the loadTopShelfContentWithCompletionHandler function and I am able to give it what it wants and it gets displayed correctlyProblem is, if I terminate the application from Xcode, I can no longer get the topshelf to work when I try and launch it again from Xcode. It is not listed as running (as a process to attach to, for example). The app runs fine, but there is no extension process launched alongside it.I can get it working again in one of two ways; either A) reboot the Apple TV, in which case I find tvOS launches the extension a few seconds after boot without me doing anything (not even highlighting my app), or, B) following the steps above if I delete the instance from the Apple TV and install it again using Xcode.Essentially, it behaves as if the top shelf extension is launched once, and only once, on bootup of the Apple TV, or on first install. It appears to get terminated when I launch the app again using xcode (e.g. with a new build or something, or even running the same build) and only A) or B) above can get it running again.Has anyone else seen this?

I am the developer of MIDIDeviceManager, an iOS and iPadOS application used by musicians to control external MIDI hardware during live performance. Before enabling any background execution mode, I would like to ask which architecture Apple intends for this type of application. What the application does The app organises the patches of a musician's MIDI instruments into Pads, Scenes and Setlists so they can be recalled during a performance. It sends MIDI to external hardware such as guitar processors, synthesisers and vocal processors, and it also receives incoming MIDI that triggers its own Scenes — typically from a Bluetooth foot controller, a wired MIDI controller, or another app on the same device. Its purpose is to function as the software equivalent of a programmable hardware MIDI controller. It is not a lyrics app or an audio player, and it produces no audio. The problem During a performance, musicians commonly run more than one app. A typical setup is lyrics or chord charts displayed in one app while a Bluetooth foot controller recalls presets on a Line 6 Helix through MIDIDeviceManager. This requires the app to keep receiving and processing incoming CoreMIDI events while another app is frontmost. Once iOS suspends the app, those events are no longer delivered and the foot controller stops working. This affects iPhone as much as iPad. Several of my TestFlight users perform with iPhone alone, where the device sits on a stand and is not touched during a song. What I have observed I tested this directly on an iPhone 17 Pro Max. With two apps running simultaneously, an app legitimately using the audio background mode continued to receive and act on incoming CoreMIDI events from a Bluetooth foot controller while backgrounded. At the same moment, MIDIDeviceManager received nothing once iOS suspended it. This suggests that, under certain circumstances, an app executing under an appropriate background mode may continue receiving CoreMIDI while backgrounded. Background modes considered audio — appears to provide the required behaviour, but my app produces no audio output. I do not wish to declare a background capability that does not accurately describe what the app does. bluetooth-central — does not appear applicable, since Bluetooth MIDI connections are established through CoreMIDI and managed by the system MIDI server rather than by my own Core Bluetooth session. I have not been able to identify any mode intended for continuous MIDI reception, so UIBackgroundModes is currently empty. A previous rejection An earlier submission did declare audio, and was rejected under Guideline 2.5.4 on 7 July 2026 (submission ID eab58179-8177-4d05-9c37-5e1006828a96): "The app declares support for audio in the UIBackgroundModes key in the Info.plist but we are unable to locate any features that require persistent audio. Background audio is intended for use by apps that provide audible content to the user while in the background, such as music player, music creation, or streaming audio apps." That assessment is correct — the app produces no audio, and I removed the key. But the functional requirement remains: the app needs to receive MIDI while another app is frontmost. I am asking here rather than resubmitting, because I would rather understand the intended architecture than guess again. My questions Which background mode, if any, is appropriate for an app whose purpose is to continue receiving and processing incoming CoreMIDI events while another app is frontmost? If background MIDI reception is supported, is CoreMIDI expected to continue delivering incoming MIDI to a backgrounded app, or is there a different recommended architecture for apps of this type? If the answer is that no background mode applies and this capability is not available to apps of this kind, I would very much appreciate knowing that clearly. I can then document the limitation for my users and design accordingly rather than pursue an unsupported approach. My objective is not to find a workaround, but to implement this the way Apple intends professional MIDI applications to work. Thank you.

I’m looking at the new BGTaskScheduler.submitTaskRequest(_:completionHandler:) API on iOS 27 that replaces the now deprecated submit(_:).* The documentation says: This method asynchronously submits the task request and invokes the completion handler with any errors that occur during submission. It also says: The completion handler may be invoked on a arbitrary queue after an arbitrary amount of delay. Do not call this method from the main thread or performance-critical contexts. I’m confused when it says “Do not call this method from the main thread.” Since the method asynchronously submits the request and reports errors later through the completion handler, I initially read this as a warning not to wait for the completion handler to be called assuming it returns quickly. But it specifically says not to call the method from the main thread, which suggests the initial call itself may perform blocking expensive work before returning (although this is confusingly stated in the same block describing the completion handler behavior). Is the intended usage to create/configure the request on the main thread, then dispatch only submitTaskRequest to a background queue, or is calling that on the main thread actually okay just like the submit(_:) API it replaced? My current code in a synchronous function running on the main thread: BGTaskScheduler.shared.register(forTaskWithIdentifier: id, using: .main) { @Sendable registeredTask in // The background continued processing task has started, use it to update progress... } let request = BGContinuedProcessingTaskRequest(identifier: id, title: title, subtitle: subtitle) request.strategy = .fail // Start the task immediately and fail if it cannot if BGTaskScheduler.supportedResources.contains(.gpu) { request.requiredResources = .gpu } do { try BGTaskScheduler.shared.submit(request) // FIXME: How to migrate to the new API? } catch { // No worries, user will just have to keep the app open until the task completes print("BGTaskScheduler request failed: \(error.localizedDescription)") } *I assume this change was made to address issues like FB21052216 (https://developer.apple.com/forums/thread/807370)

I implemented BGContinuedProcessingTask in my app and it seems to be working well for everyone except one user (so far) who has reached out to report nothing happens when they tap the Start Processing button. They have an iPhone 12 Pro Max running iOS 26.1. Restarting iPhone does not fix it. When they turn off the background processing feature in the app, it works. In that case my code directly calls the function to start processing instead of waiting for it to be invoked in the register block (or submit catch block). Is this a bug that's possible to occur, maybe device specific? Or have I done something wrong in the implementation? func startProcessingTapped(_ sender: UIButton) { if isBackgroundProcessingEnabled { startBackgroundContinuedProcessing() } else { startProcessing(backgroundTask: nil) } } func startBackgroundContinuedProcessing() { BGTaskScheduler.shared.register(forTaskWithIdentifier: taskIdentifier, using: .main) { @Sendable [weak self] task in guard self != nil else { return } startProcessing(backgroundTask: task as? BGContinuedProcessingTask) } let request = BGContinuedProcessingTaskRequest(identifier: taskIdentifier, title: title, subtitle: subtitle) request.strategy = .fail if BGTaskScheduler.supportedResources.contains(.gpu) { request.requiredResources = .gpu } do { try BGTaskScheduler.shared.submit(request) } catch { startProcessing(backgroundTask: nil) } } func startProcessing(backgroundTask: BGContinuedProcessingTask?) { // FIXME: Never called for this user when isBackgroundProcessingEnabled is true }