Post

Replies

Boosts

Views

Activity

Reply to Compile Failure on NSXPCInterface Initializer
Haven't been able to solve this one yet. I have some new evidence though. It appears there's difference in behavior between Intel and Silicon based systems. My machine is Intel, and most of my team is on Apple Silicon. We recently updated a couple of our build machines (Intel-based), and they started seeing the same issue. Our Apple Silicon machines do not see this issue. Our build machines were updated from: OS: Sonoma 14.5 -> Sequoia 15.7.1 XCode: 16.1 (or earlier) -> 16.4
Oct ’25
Reply to Compile Failure on NSXPCInterface Initializer
I believe I am using the default toolchain. I do not see a Toolchains section in my XCode menu, and when I check my command line tools, it is set to XCode 16.4 (16F6). If I remove all source files, it builds successfully. When I add the single file with the doNothing function, it fails. However, I'm getting a slightly different error this time: Cannot convert value of type '(any XPCServiceDelegate).Type' to expected argument type 'Protocol' If I specify the type of proto as Protocol, I get the error: Cannot convert value of type 'ObjectiveC.`Protocol`' to expected argument type '__ObjC.`Protocol`'
Aug ’25
Reply to Compile Failure on NSXPCInterface Initializer
@DTS Engineer, I'm still getting the issue even with the Foundation module qualifier in the front of NSXPCInterface. The strangest thing is that I have others on my team that can build successfully with the same commit on the same version of XCode. I suspect something more environmental to my machine. I noticed that when I Jump to Definition on NSXPCInterface, XCode sometimes points me to the Swift definition of the interface, like below: @available(macOS 10.8, *) open class NSXPCInterface : NSObject { public /*not inherited*/ init(with protocol: Protocol) unowned(unsafe) open var `protocol`: Protocol //... } and other times it will point me to NSXPCConnection.h, like below: API_AVAILABLE(macos(10.8), ios(6.0), watchos(2.0), tvos(9.0)) @interface NSXPCInterface : NSObject // Factory method to get an NSXPCInterface instance for a given protocol. Most interfaces do not need any further configuration. Interfaces with collection classes or additional proxy objects should be configured using the methods below. + (NSXPCInterface *)interfaceWithProtocol:(Protocol *)protocol; // The Objective C protocol this NSXPCInterface is based upon. @property (assign) Protocol *protocol; //... @end Also, the Autocomplete shows the Initializer with the protocol labeled argument and not with. I attempted changing to use "protocol" for the label, but that's not working either.
Aug ’25
Reply to Multiple NSXPCConnections, Invalidation, and Reconnection to launchd-managed service
Quinn, Thank you for your response. This does confirm my understanding of NSXPCConnections. This question was actually the result of attempting to debug contention between two "unit" tests in our code that would each succeed by themselves when run, but then sometimes fail when run in the suite. I think the crux of my issue here is that these are indeed not unit tests because we are using a dummy XPC service to facilitate responses to our XPC client abstraction test cases. Thank you for recommending the testing with the anonymous listener; this approach would remove our need of spooling-up the dummy XPC service in the first place.
Nov ’21