Oh, I was about to add that with setConnectionCodeSigningRequirement called on the listener it’s even harder to log on the service side that something happened with the connection. In that case, the listener method of NSXPCListenerDelegate is not called at all. This means I can’t set up an invalidation handler on a new connection. Is there any way to (in code) notice from the service side that the connection was invalidated due to a code signing requirement failure? At the moment, the only workaround I'm aware of is to run Console.app while trying to start the launch daemon and then spot xpc_support_check_token: <private> error: <private> status: -67050 in the logs. Thanks for the tip about logging, I wasn't aware of that. The launch daemon is mostly written in Go, with a small part in Objective-C that handles all of the XPC stuff and I don't have a whole lot of knowledge about Objective-C.

In the rare situation where the app cannot contact the launch daemon due to not satisfying the code signing requirement, I'd like the Go part of the launch daemon to leave a clear message in the log file. It already logs there a bunch of other information and this would be the go-to place which our users and customer support check. As it stands, on the client side I get NSXPCConnectionInterrupted and no indication of a problem on the service side. I'm writing up a debug log message on the client side that points towards Console.app and looking for xpc_support_check_token: <private> error: <private> status: -67050 if the client encounters NSXPCConnectionInterrupted. But as I understand, a connection can get interrupted for a multitude of reasons. It'd be nice to get a clearer indication of a code signing problem on the service side without having to go through Console.app. (In this message, I used "the launch daemon" and "the service side" interchangeably.)