Damn that was a very good suggestion, it never crossed my mind. It greatly reduced my code complexity and allowed me to use the Codable versions of send() and incomingMessageHandler while still being able to use the XPCEndpoint property and being able to send multiple kinds of messages wrapped inside the associated values of the single enumeration type. Thanks!

Thanks Quinn for your very informative answer. Your code does work on my side as well, and is what I would generally use. However it has a pain point for me - I don't see how I'm able to send various kinds of Codable conforming typed messages over the XPC connection. That forced me into using XPCDictionary. How can one XPCSession transfer let's say two distinct types of Codable messages? struct EndpointCheckinMessage: Codable { var endpoint: XPCEndpoint var endpointBundleID: String } struct SpecificClientMessage: Codable { var title: String var description: String } How would one XPCSession send both of these messages efficiently to the daemon? Because my solution was initially wrap these into a single struct: struct GeneralClientMessage: Codable { var kind: MessageKind // EndpointCheckinMessage, SpecificClientMessage, etc. var body: Data // This would contain the above types encoded with `JSONEncoder`. } And that's where I hit this issue and had to resort to XPCDictionary. What would be natural to me is being able to define multiple Codable incomingMessageHandler closures, one for each kind of closure. But I can't see an option for that anywhere - not in the direct initializers of XPCListener, nor in XPCPeerHandler. Do you have any recommendations for this scenario? I'm pretty sure I'm doing something wrong, I'm fairly unfamiliar with the low-level XPC APIs.

Thank you, it is nice to know these Swift-based CSR APIs are coming in macOS 26.0. However, I'm still wondering what these two functions are: xpc_session_set_peer_code_signing_requirement xpc_listener_set_peer_code_signing_requirement Because they are new in macOS 14.4, but seem to have basically zero use in Swift as per above. xpc_listener_t and xpc_session_t seem to be completely new objects from macOS 13.0, however the xpc C API - the convention they seem to follow - is way older. The two objects mentioned however gained a full set of new functions in macOS 13.0 and 14.0. E.g.: xpc_listener_create is a macOS 14.0+ function xpc_session_create_mach_service is a macOS 13.0+ function How am I supposed to treat these compared to the old C API using xpc_connection_create_mach_service + either XPC_CONNECTION_MACH_SERVICE_PRIVILEGED or XPC_CONNECTION_MACH_SERVICE_LISTENER? Are they supposed to be an easier-to-use session based API?

@DTS Engineer Thank you for your reply. Using the individual certificates locally is indeed my current setup. However, the reason why I want to switch is that cloud signing would vastly decrease the complexity of my signing processes, as I currently need to juggle many different certificate types on my CI/CD systems (e.g. Apple Development, Apple Distribution, Developer ID Application, etc.) - downloading them one by one from a secret storage. If I understand correctly, this exact case would be one of the largest advantages of cloud signing: having the cloud server sign artifacts removes the need for manually making certificates available on the CI/CD runner mac that needs to sign the apps. I trust this bug can be corrected in time, as it's a rather major selling point of cloud signing. It's one of its two main uses - safe distribution outside of the App Store (the other being distribution inside the App Store).

This issue has been filed in Feedback Assistant: FB16835802.

I've been looking at this issue more and what's even more interesting is that if I'm using an iOS app, the whole process works. An Apple Distribution (Managed) certificate appears in my account. I did check and as account holder and single user developer program member I have both Distribution and Developer ID cloud certificates enabled (I can't even turn them off).

This is a bug even today, on iOS 18.0.

I'm seeing very similar problems. However I am manually putting together a video from photos in an album, so it's even weirder, given I have full control over the order of frames.

I truly believe you are right. Either the block parameter should be marked @Sendable on Apple's side, or the function should be nonisolated. This has probably been overlooked.