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.