I have certain restrictions on the language I can use, and C is the only option for me. I am not using the C API because of some specific API that only works in that context. Thanks Quinn for the information. K

Lets say there are 3 certificates in the certificate chain- apple root, intermediate, leaf. The xpc client is codesigned using the leaf certificate. Does xpc_connection_set_peer_code_signing_requirement verify the entire certificate chain?

In my requirement, there is a status flag in the server. Any client can change this flag and I want the other clients to know about this change when it happens.

How do Dispatch sources come into this? I have a launchd daemon(written in golang) that does some tasks. I want it to communicate with an executable, so I used XPC for communication. When I started the daemon, the XPC server kept crashing. I assumed it had something to do with dispatch_main(), so I used a dispatch source with "DISPATCH_SOURCE_TYPE_MACH_RECV". This solved my issue. (do you know if there is a better way to do this?) Under what circumstances does your launchd daemon need to shut down an XPC listener gracefully? I am thinking of cases when the system shuts down, restarts, or the daemon crashes.

Hey Quinn, I dont think I was clear regarding my implementation of the daemon. So I am attaching a link to the code. Its super small and easy to go through. Please have a look. I still have a few questions- 1. XPC Lifecycle My Golang daemon is continuously running in the background. I added <key>MachServices</key> field in my daemon's plist file to use XPC. I have C code that contains XPC logic, which I call from Golang(using Cgo). My question: In my implementation I am using Golang to call C code, how is the XPC lifecycle affected by this? Is the XPC listener launched on demand, or does it stay running as long as the daemon? 2. freeing up variables I am using dispatch_resume that doesnt return, so how can I free the dispatch source, queue and the XPC connection object variables ? 3. Your daemon is managed by launchd and that owns the named XPC endpoint. Do you mean launchd owns the endpoint? 4. The ideal pattern is for your daemon to support transactions. Do you mean using xpc_transaction_begin and xpc_transaction_end?

I’m still not sure why you’re calling dispatch_resume at all. XPC listeners don’t need that in general. I am assuming that I still need to call dispatch_main() or do something similar. I came across this post which says to set RunLoopType property to NSRunLoop. (I am using C APIs for my XPC code, will NSRunLoop work in this case?) If this is something I can use, do I need to make any changes in my XPC listener code? Is there any other alternative if I dont use dispatch_main()?

Likewise, if your daemon checks in but then stops servicing the listener, it’ll be similarly non-functional. What do you mean by "servicing" the listener? Can you elaborate?