So in auditing the complete output of sfltool dumpbtm on multiple OS versions I cannot find one single example of an Apple-defined service which uses these bundle nested daemons. They're all "legacy" in the traditional location in the filesystem. If Apple's not eating their own dogfood here then that's all I really need to know.

No idea if this "pending authorization" "disposition" is relevant or not, but I do not know what else I as a user can possibly authorize beyond flipping the switch in System Settings. #9: UUID: 0C6D2CA3-9BAF-45D8-819B-604F52203F56 Name: SMAppServiceSampleCode Developer Name: ABCDEFG Team Identifier: *****437 Type: app (0x2) Disposition: [disabled, allowed, visible, not notified] (2) Identifier: identifier "com.example.apple-samplecode.SMAppServiceSampleCode8B59GX9437" and anchor apple generic and certificate leaf[subject.CN] = "Apple Development: user@host.com (XXXXXXX)" and certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */ URL: file:///Applications/SMAppServiceSampleCode.app/ Generation: 0 Bundle Identifier: com.example.apple-samplecode.SMAppServiceSampleCode8B59GX9437 Embedded Item Identifiers: #1: com.xpc.example.agent #10: UUID: F8746E58-2ADA-4840-82E7-9DCC1F77FD72 Name: SampleLaunchAgent Developer Name: (null) Type: daemon (0x10) Disposition: [enabled, allowed, visible, notified] (pending authorization) (27) Identifier: com.xpc.example.agent URL: Contents/Library/LaunchDaemons/com.xpc.example.agent.plist Executable Path: Contents/Resources/SampleLaunchAgent Generation: 2

And just to verify that it is in fact signed (team ID partially redacted): % codesign -dv /Applications/SMAppServiceSampleCode.app/Contents/Resources/SampleLaunchAgent Executable=/Applications/SMAppServiceSampleCode.app/Contents/Resources/SampleLaunchAgent Identifier=SampleLaunchAgent Format=Mach-O thin (arm64) CodeDirectory v=20400 size=853 flags=0x0(none) hashes=16+7 location=embedded Signature size=4786 Signed Time=Sep 12, 2025 at 2:22:55 PM Info.plist=not bound TeamIdentifier=******9437 Sealed Resources=none Internal requirements count=1 size=188

It does seem to be a permissions issue. If I revert back to putting the service in /Library/LaunchAgents and call SMAppService.agent(plistName: "com.xpc.example.agent.plist") as demonstrated I can establish the XPC session and the code works as intended. That makes my claims of brokenness thoroughly, regretably invalid. It works, it's just not a complete example. Once I change the Copy File phase to throw the build product into /Library/LaunchDaemons" and call SMAppService.daemon(plistName: "com.xpc.example.agent.plist")instead (including passing the.private` flag when establishing the session), all the trouble begins. I manually did a chmod 600 and chown root on the service binary and the plist but launchd doesn't like that any better. I'm completely ruling out any .plist errors since I have not changed a single thing in that file and the same exact file works as a LaunchAgent. If I try to register the (root owned and non-group/world readable) plist manually then this happens: % sudo launchctl load /Applications/SMAppServiceSampleCode.app/Contents/Library/LaunchDaemons/com.xpc.example.agent.plist /Applications/SMAppServiceSampleCode.app/Contents/Library/LaunchDaemons/com.xpc.example.agent.plist: Domain does not support specified action Load failed: 125: Domain does not support specified action This is not an error I have any memory of dealing with before but the tiny handful of search results I can dig up also seem to involve permissions in unrelated third-party GitHub issues. The demo code using those newer objects is not something I can run but I don't realistically see any difference in what that code is doing and what mine is doing with the non-OOP API. My best guesses at this point are: Free developer certs are not capable of signing LaunchDaemons appropriately or Some other magical blessing is required to be applied to this file other than root ownership and 600 mode flags.

I have noticed that launchd is changing my status to 78 at times which I vaguely remember is a permissions issue but I can't find the relevant documentation anymore. I'm not actually attempting to do anything even remotely privileged in the code yet; the example service is unchanged save for a liberal blanketing of print() calls to try and see if anything is ever running. Nothing ever shows up on the console so I have no clue what would lack permission to run if I'm getting SMAppService.Status.enabled back from the service object. Does the nested launchd job not inherit the parent app's entitlements or something?

My reasoning is difficult to phrase in a way that will not come across as combative or insulting, but suffice to say I explicitly object to the existence of most--if not all--of the features that Apple has shipped in more recent releases and prefer to keep them all out of my house so to speak. I only update the OS when a machine dies and I have to buy a new one. If there's a solid guarantee that all of this is better in 15 then I'll absolutely bite that bullet anyway, but right now I'm essentially just doing a feasibility study and cannot destabilize everything else in my world just to find out whether or not maturity has crept in. My goal is simply an app with an overly-privileged helper that will never appear in any app store or be run on any machine that doesn't belong to a person who immediately disables SIP as a matter of principle. I've already removed all the PackageBuilder stuff as it was very much in the way of testing--that was the only sample project I could find that was close to what I wanted but Google's pretty terrible these days. If there's a better starting point I'll happily give that a shot instead. You are very correct on the code signing thing. Xcode mysteriously lost my settings for one target in total silence at some point--probably during one of its many, many crashes that left bizarre patterns all over my video RAM requiring all the restarts in the first place. I've now corrected that setting but the service is still acting mute. I am just using a free developer profile if that has anything to do with it. Last bit of info I can dredge up is that sudo launchctl list does indicate that the service is known to exist and has a zero status; it is simply not responding to the "client" app upon invocation and I have thus far been unable to find any output from it anywhere in Console.app: - 0 com.xpc.example.agent Tried adding the .private flag to xpc_session_create_mach_service just in case and there was no change in behavior with that, either Whatever all is going on here, there really needs to be a timeout option for these XPC calls. I know that GCD has mechanisms to implement this and I'm truly gobsmacked to see them not being exercised on something so pervasive and evangelized. It's like it was all designed to guarantee that deadlocks are a common failure mode rather than a freak occurrence. I will look through that "anonymous listener" approach with fresher eyes tomorrow but the first thing that jumps out at me is the big yellow box that says: ...if you’re developing a launchd daemon that performs privileged operations on behalf of your app, you can’t use this technique to debug your privileged code because it’s not running in a privileged process. Seems like a cul-de-sac. Levin's XPoCe looks nice but seems to want a PID I don't believe I have to feed it.

After changing literally nothing, I was eventually able to get a register invocation to succeed and an enabled response to come back from status. Symptomatically, it seems like some kind of non-deterministic race condition, but I sincerely have no clue what is going on with that given the limited visibility I have into the execution. Once registered, invoking the test option successfully initializes the XPC session, but the synchronous message send deadlocks, waiting for a response that never comes. I do not see any evidence that com.xpc.example.agent is actually running at any point no matter what my registration status is but I could be looking in the wrong place. How are you supposed to debug that handoff? Console filters? Additionally, it seems as though I lose my right to execute in the background on every restart and have to re-visit the deeply-nested System Settings panel horrorshow over and over. The documentation vaguely alludes to something like this, but I can't really tell what it's trying to say. I'd like to know if this is indeed the expected behavior so I can stick to the deprecated bless API that's more predictable. This new stuff looks great on paper but I would not feel comfortable shipping anything that uses it given what I've experienced so far.