OSAllocatedUnfairLock has two different methods for executing a block of code with the lock held: withLock() and withLockUnchecked(). The only difference between the two is that the former has the closure and return type marked as Sendable. withLockUnchecked() has a comment (that is for reasons I do not understand not visible in the documentation) saying: /// This method does not enforce sendability requirement /// on closure body and its return type. /// The caller of this method is responsible for ensuring references /// to non-sendables from closure uphold the Sendability contract. What I do not understand here is why Sendable conformance would be needed. These function should call this block synchronously in the same context, and return the return value through a normal function return. None of this should require the types to be Sendable. This seems to be supported by this paragraph of the documentation for OSAllocatedUnfairLock: /// This lock must be unlocked from the same thread that locked it. As such, it /// is unsafe to use `lock()` / `unlock()` across an `await` suspension point. /// Instead, use `withLock` to enforce that the lock is only held within /// a synchronous scope. So, why does this Sendable requirement exist, and in practice, if I did want to use withLockUnchecked, how would I "uphold the Sendability contract"? To summarise the question in a more concise way: Is there an example where using withLockUnchecked() would actually cause a problem, and using withLock() instead would catch that problem?

I have an application, it has main process and some child processes. As we want those child processes to have their own minimum sandbox privilege, not inheriting from parent process, we plan to use XPCService which uses a NSTask to launch those child processes, so those child processes can have its own sandbox privilege. We plan to deliver the application to Mac App Store, so process mode is: the sandboxed main process builds connections to the unsandboxed XPCService, the unsandboxed XPCService launch those sandboxed child processes. Can this process mode pass the Mac App Store rules? I see, there is a rule that all processes must be sandboxed, including XPCService. But I tested locally, the Application downloaded from Mac apple store also launches unsandboxed XPCService, like OneDrive. Do you have any suggestions for my application scenario, sandboxed child processes having its own privilege not inheriting from parent?

I've been experimenting with the new low-level Swift API for XPC (XPCSession and XPCListener). The ability to send and receive Codable messages is an appealing alternative to making an @objc protocol in order to use NSXPCConnection from Swift — I can easily create an enum type whose cases map onto the protocol's methods. But our current XPC code validates the incoming connection using techniques similar to those described in Quinn's "Apple Recommended" response to the "Validating Signature Of XPC Process" thread. I haven't been able to determine how to do this with XPCListener; neither the documentation nor the Swift interface have yielded any insight. The Creating XPC Services article suggests using Xcode's XPC Service template, which contains this code: let listener = try XPCListener(service: serviceName) { request in request.accept { message in performCalculation(with: message) } } The apparent intent is to inspect the incoming request and decide whether to accept it or reject it, but there aren't any properties on IncomingSessionRequest that would allow the service to make that decision. Ideally, there would be a way to evaluate a code signing requirement, or at least obtain the audit token of the requesting process. (I did notice that a function xpc_listener_set_peer_code_signing_requirement was added in macOS 14.4, but it takes an xpc_listener_t argument and I can't tell whether XPCListener is bridged to that type.) Am I missing something obvious, or is there a gap in the functionality of XPCListener and IncomingSessionRequest?

I'm trying to reproduce a case when there are more dispatch queues than there are threads serving them. Is that a possible scenario?

I'm working on a macOS application that deals with a few external dependencies that can only be compiled for intel (x86_64) but I want the app to run natively on both arm and x86_64. One idea I have been playing with is to move the x86_64 dependencies to an xpc service compiled only as x86_64 and use the service only the intel machine. However, I can't figure out how to setup my project to compile everything at once... Any ideas? Is this even possible? If not, I'm open to suggestions... Thanks

Hello, im currently rewriting my entire network stuff to swift concurrency. I have a Swift Package which contains the NWConnection with my custom framing protocol. So Network framework does not support itself concurrency so I build an api around that. To receive messages I used an AsyncThrowingStream and it works like that: let connection = MyNetworkFramework(host: "example.org") Task { await connection.start() for try await result in connection.receive() { // do something with result } } that's pretty neat and I like it a lot but now things got tricky. in my application I have up to 10 different tcp streams I open up to handle connection stuff. so with my api change every tcp connection runs in it's own task like above and I have no idea how to handle the possible errors from the .receive() func inside the tasks. First my idea was to use a ThrowingTaskGroup for that and I think that will work but biggest problem is that I initially start with let's say 4 tcp connections and I need the ability to add additional ones later if I need them. so it seems not possible to add a Task afterwards to the ThrowingTaskGroup. So what's a good way to handle a case like that? i have an actor which handles everything in it's isolated context and basically I just need let the start func throw if any of the Tasks throw I open up. Here is a basic sample of how it's structured. Thanks Vinz internal actor MultiConnector { internal var count: Int { connections.count } private var connections: [ConnectionsModel] = [] private let host: String private let port: UInt16 private let parameters: NWParameters internal init(host: String, port: UInt16, parameters: NWParameters) { self.host = host self.port = port self.parameters = parameters } internal func start(count: Int) async throws -> Void { guard connections.isEmpty else { return } guard count > .zero else { return } try await sockets(from: count) } internal func cancel() -> Void { guard !connections.isEmpty else { return } for connection in connections { connection.connection.cancel() } connections.removeAll() } internal func sockets(from count: Int) async throws -> Void { while connections.count < count { try await connect() } } } // MARK: - Private API - private extension MultiConnector { private func connect() async throws -> Void { let uuid = UUID(), connection = MyNetworkFramework(host: host, port: port, parameters: parameters) connections.append(.init(id: uuid, connection: connection)) let task = Task { [weak self] in guard let self else { return }; try await stream(connection: connection, id: uuid) } try await connection.start(); await connection.send(message: "Sample Message") // try await task.value <-- this does not work because stream runs infinite until i cancel it (that's expected and intended but it need to handle if the stream throws an error) } private func stream(connection: MyNetworkFramework, id: UUID) async throws -> Void { for try await result in connection.receive() { if case .message(_) = result { await connection.send(message: "Sample Message") } // ... more to handle } } }

I run the following code in an actor: func aaa() async throws -> Data { async let result = Task( operation: { ... decompressing data through try (data as NSData).decompressed(using: .lzfse) as Data } ).result switch await result { case .success(let value): return value case .failure(let error): throw error } I do it this way because I do not want to block the actor by decompression, and there is no state change in the actor afterwards. I would say that the actor plays no significant role here. Important is that many (14) concurrent tasks run in parallel, however NOT on the same data. It runs fine for a while (dozens/hundreds of data decompressed), and then the following happens: Activity Monitor (macOS GUI tool) shows almost none User CPU time, and approx. 75% System CPU time. The rest is idle. (When it runs fine, User CPU time is 95+%) When I pause the run in Xcode (in release config it behaves the same), all threads are in mach_msg2_trap #0 0x0000000180ac21f4 in mach_msg2_trap () #1 0x0000000180ad4b24 in mach_msg2_internal () #2 0x0000000180ac52fc in vm_copy () #3 0x0000000180916b78 in szone_realloc () #4 0x000000018093cfb0 in _malloc_zone_realloc () #5 0x000000018093d7e8 in _realloc () #6 0x0000000180bb8a10 in __CFSafelyReallocate () #7 0x0000000181d00e30 in _NSMutableDataGrowBytes () #8 0x0000000181ce2630 in -[NSConcreteMutableData appendBytes:length:] () #9 0x00000001823c30d8 in -[_NSDataCompressor processBytes:size:flags:] () #10 0x00000001823c32c4 in -[NSData(NSDataCompression) _produceDataWithCompressionOperation:algorithm:handler:] () #11 0x00000001823c3598 in -[NSData(NSDataCompression) _decompressedDataUsingCompressionAlgorithm:error:] () It looks like something is wrong with safe reallocation, however if this have been a bug, then all macOS is stuck. Any idea, please?

CIFormat static var such as RGBA16 give concurrency warnings: Reference to static property 'RGBA16' is not concurrency-safe because it involves shared mutable state; this is an error in Swift 6 Should all these formats be static let to suppress the warnings (future errors)?

Greetings! I've added a Matter accessory via the Apple Home app. In my app, I'm attempting to commission this device and add it to my fabric. However, when I try to open the commissioning window, I receive an error stating, MTRBaseDevice doesn't support openCommissioningWindowWithDiscriminator over XPC. It appears that opening a commissioning window via an XPC connection is not yet supported. Is there another method to commission the device? Can I retrieve the setup payload from the MTRBaseDevice object or the shared MTRDeviceController? Here's the simplified version of my code: var home: HMHome // HMHome received via HMHomeManager var accessory: HMAccessory = home.accessory[0] // my Matter-supported accessory let deviceController = MTRDeviceController.sharedController( withID: home.matterControllerID as NSCopying, xpcConnect: home.matterControllerXPCConnectBlock ) let device = MTRBaseDevice( nodeID: accessory.matterNodeID as NSNumber, controller: deviceController ) device.openCommissioningWindow( withDiscriminator: 0, duration: 900, queue: .main) { payload, error in if let payload { // payload not received } else if let error { // I'm getting here "Error Domain=MTRErrorDomain Code=6 "(null)"" // and "MTRBaseDevice doesn't support openCommissioningWindowWithDiscriminator over XPC" logged in the console print(error) }

I am currently working on planning a multi-component software system that consists of an Audio Server Plugin and an application for user interaction. I have very little experience with IPC/XPC and its performance implications, so I hope I can find a little guidance here. The Audio Server plugin publishes a number of multi-channel output devices on which it should perform computations and pass the result on to a different Core Audio device. My concerns here are: Can the plugin directly access other CoreAudio devices for audio output or is this prohibited by the sandboxing? If it cannot, would relaying the audio data via XPC be a good idea in terms of low latency stability? Can I use metal compute from within the Audio Server plugin? I have not found any information about metal related sandboxing entitlements. I am also concerned about performance implications as above. Regarding the user interface application, I would like to know: If a process that has not been started by launchd can communicate with the Audio Server plugin using XPC. If not, would a user agent instead of an app be a better choice? Or are there other communication channels that would work with sandboxing? Thank you very much! Andreas

Hello community, I am in search of a tutorial that comprehensively explains the proper utilization of SwiftData for updating model data in a background thread. From my understanding, there is extensive coverage on creating a model and loading model data into a view, likely due to Apple's detailed presentation on this aspect of SwiftData during WWDC23. Nevertheless, I am encountering difficulties in finding a complete tutorial that addresses the correct usage of SwiftData for model updates in a background thread. While searching the web, I came across a few discussions on Stack Overflow and this forum that potentially provide an approach. However, they were either incomplete or proved ineffective in practical application. I would greatly appreciate any links to tutorials that thoroughly cover this topic.

Hi, Despite the following code works great on Windows and Linux (well, there is an OS layer stripped from the code), it hangs on macOS (pseudocode first): create non-blocking socketpair(AF_UNIX, SOCK_STREAM, ...); + a couple of fcntl(fd, ..., flags | O_NONBLOCK) spawn 128 pairs of threads (might be as little as 32, but will need several iterations to reproduce). Of course, there is the errno check to ensure there are no errors but EWOULDBLOCK / EAGAIN readers read a byte 10000 times: for (...) { while (read(fd[1]...) < 1) select(...); r++;} writers write a byte 10000 times: for (...) { while (write(fd[0]...) < 1) select(...); w++;} Join writers; Join readers; On Linux/Windows with the iterations number really cranked up, I'm getting a socket buffer overflow, so ::write returns EWOULDBLOCK, then I'm waiting on a socket until it's ready, continue, and after joining both sets of threads I see that bytes-read is equal to bytes-written, everything fine. However, on macOS I quickly end up in a strange lock when writers are waiting on ::select(...., &write_fds, ...) and readers on the corresponding ::select(..., &read_fds, ...); I have really no idea how that could happen except that the read/write is not thread-safe. However, it looks like POSIX docs and manpages state that it is (at least, reentrant). Could anyone point me in the right direction? Detailed code below: std::atomic<int> bytes_written(0); std::atomic<int> bytes_read(0); static constexpr int k_packets = 10000; static constexpr int k_threads = 32; std::vector<std::thread> writers; std::vector<std::thread> readers; writers.reserve(k_threads); readers.reserve(k_threads); for (int i = 0; i < k_threads; ++i) { writers.emplace_back([fd_write = fd[1], &bytes_written]() { char data = 'x'; for (int i = 0; i < k_packets; ++i) { while (::write(fd_write, &data, 1) < 1) { fd_set writefds; FD_ZERO(&writefds); FD_SET(fd_write, &writefds); assert(errno == EAGAIN || errno == EWOULDBLOCK); int retval = ::select(fd_write + 1, nullptr, &writefds, nullptr, nullptr); if (retval < 1) assert(errno == EAGAIN || errno == EWOULDBLOCK); } ++bytes_written; } }); readers.emplace_back([fd_read = fd[0], &bytes_read]() { char data; for (int i = 0; i < k_packets; ++i) { while (::read(fd_read, &data, 1) < 1) { fd_set readfds; FD_ZERO(&readfds); FD_SET(fd_read, &readfds); assert(errno == EAGAIN || errno == EWOULDBLOCK); int retval = ::select(fd_read + 1, &readfds, nullptr, nullptr, nullptr); if (retval < 1) assert(errno == EAGAIN || errno == EWOULDBLOCK); } ++bytes_read; } }); } for (auto& t : writers) t.join(); for (auto& t : readers) t.join(); assert(bytes_written == bytes_read);

Swift Concurrency Resources: DevForums tags: Concurrency The Swift Programming Language Concurrency > Concurrency documentation WWDC 2022 Session 110351 Eliminate data races using Swift Concurrency — This ‘sailing on the sea of concurrency’ talk is a great introduction to the fundamentals. WWDC 2021 Session 10134 Explore structured concurrency in Swift — The table that starts rolling out at around 25:45 is really helpful. Dispatch Resources: DevForums tags: Dispatch Dispatch documentation — Note that the Swift API and C API, while generally aligned, are different in many details. Make sure you select the right language at the top of the page. Dispatch man pages — While the standard Dispatch documentation is good, you can still find some great tidbits in the man pages. See Reading UNIX Manual Pages. Start by reading dispatch in section 3. WWDC 2015 Session 718 Building Responsive and Efficient Apps with GCD [1] WWDC 2017 Session 706 Modernizing Grand Central Dispatch Usage [1] Avoid Dispatch Global Concurrent Queues DevForums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] These videos may or may not be available from Apple. If not, the URL should help you locate other sources of this info.

Can't understand why this compiles extension HomeReducer { @MainActor @Observable final class State: BaseState { var isPresentingSubscription = false } } class BaseState {} but this gives an error Call to main actor-isolated initializer 'init()' in a synchronous nonisolated context extension HomeReducer { @MainActor @Observable final class State { var isPresentingSubscription = false } } extension DependencyValues { var homeView: @Sendable () -> HomeView { HomeKey().value } private struct HomeKey: DependencyKey { typealias Value = @Sendable () -> HomeView let liveValue: Value = { HomeView(store: Store(initialState: HomeReducer.State(), reducer: HomeReducer())) } let testValue: Value = { fatalError("testValue not implemented") } var previewValue: Value = { fatalError("previewValue not implemented") } } }

I have another NSXPC problem, and the problem goes like this NSXPC server implements an interface -(void) callbackWithInfo:(NSDictionary*)log reply:(void (^)(bool))action; The NSXPC client implements a method that will call the interface in a loop and perform a timeout operation. If the server returns to the interface and does not call the action after 1s, the client will perform subsequent operations. The callbackWithInfo interface is then called again, and the cycle continues. client code: The general structure is as follows while(true){ dispatch_semaphore_t semaphore = dispatch_semaphore_create(0); dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ [serverProxy callbackWithInfo:InfoDic reply:^(bool action) { if(flag != NO){ flag = action; } }]; dispatch_semaphore_signal(semaphore); }); if(dispatch_semaphore_wait(semaphore, dispatch_time(DISPATCH_TIME_NOW, self.waitTime *NSEC_PER_MSEC)) != 0){ NSLog(@"flag: %d", flag); } sleep(0.1); } If the action callback is not invoked on the server, the number of FDS on the client increases. As a result, the process cannot open the file, or too much program context information is generated. As a result, the NSXPC interface fails to be invoked. Now I can not operate on the server side, how can the client side implement the code to ensure that the action will not be punished, and the fd will not increase.

class CalculatorViewModel : NSObject, ObservableObject, Identifiable { var id = UUID() @Published var output = "Disconnected" @Published var connected = false @Published var databasePath = String() enum itemType : Int{ case angle = 1 case degree = 2 case grip1 = 3 case grip2 = 4 } struct test_Array: Identifiable { var id = UUID() var time: String var swingNum : Int var dataSeqInSwing: Int var timeStampInSeq: Double var itemType: Int var value: Double } @Published var testDBdata = [test_Array] () ..... private var centralManager: CBCentralManager? func connectCalculator() { output = "Connecting..." centralQueue = DispatchQueue(label: "test.discovery") centralManager = CBCentralManager(delegate: self, queue: centralQueue) } .... func peripheral(_ peripheral: CBPeripheral, didUpdateValueFor characteristic: CBCharacteristic, error: Error?) { ..... if characteristic.uuid == outputCharUUID, var data = characteristic.value { ..... DispatchQueue.main.async() { for index in tupleSets { strItemSets = index.components(separatedBy: ",") ....... var itemN = 1 for indexStr in strItemSets { self.golfDBdata[numDB].dataSeqInSwing = countItem. <= Error self.golfDBdata[numDB].itemType = itemN self.golfDBdata[numDB].value = Double(strItemSets[itemN]) ?? 0.0

I implemented a multithreaded app, but there was a thread-related crash in the app, I don't understand why this happened, the corresponding stack trace is as follows. Thread 15 Crashed:: Dispatch queue: com.apple.root.default-qos 0 libsystem_kernel.dylib 0x1a849ad98 __pthread_kill + 8 1 libsystem_pthread.dylib 0x1a84cfee0 pthread_kill + 288 2 libsystem_c.dylib 0x1a840a340 abort + 168 3 libc++abi.dylib 0x1a848ab08 abort_message + 132 4 libc++abi.dylib 0x1a847a950 demangling_terminate_handler() + 336 5 libobjc.A.dylib 0x1a8370320 _objc_terminate() + 144 6 libc++abi.dylib 0x1a8489ea4 std::__terminate(void (*)()) + 20 7 libc++abi.dylib 0x1a8489e40 std::terminate() + 64 8 libdispatch.dylib 0x1a830c1c8 _dispatch_client_callout + 40 9 libdispatch.dylib 0x1a831da04 _dispatch_root_queue_drain + 680 10 libdispatch.dylib 0x1a831e104 _dispatch_worker_thread2 + 164 11 libsystem_pthread.dylib 0x1a84cc324 _pthread_wqthread + 228 12 libsystem_pthread.dylib 0x1a84cb080 start_wqthread + 8

Hi team, We found that the app reported a lot of crash stacks, and the top of the stack had the libxpc library feature, but we could not find the reason. These issues have only emerged since iOS 16 and are growing, can you provide some clues or provide some solutions? Thanks! Crash backtrace can be seen as follows. _ OS Version: 16.6.1 (20G81) Report Version: 104 SDK start time: 2023-09-20 18:42:40 RDM SDK Version: 2.7.27.1 RDM user id : 119902290602 RDM DeviceId: 0DB20076-F323-468F-9EEC-080B77A00E05 RDM APP KEY: 7c35edbf90 Last Exception : 0 libxpc.dylib 0x000000020a019e98 __xpc_dictionary_insert + 96 1 libxpc.dylib 0x000000020a019e84 __xpc_dictionary_insert + 76 2 libxpc.dylib 0x000000020a01b944 __xpc_dictionary_deserialize_apply + 68 3 libxpc.dylib 0x000000020a01b8cc __xpc_dictionary_apply_wire_f + 136 4 libxpc.dylib 0x000000020a018da4 __xpc_dictionary_deserialize + 108 5 libxpc.dylib 0x000000020a00cdf4 __xpc_array_deserialize + 204 6 libxpc.dylib 0x000000020a01b9ec __xpc_dictionary_unpack_value + 120 7 libxpc.dylib 0x000000020a01bbf0 __xpc_dictionary_unpack_value_and_vend + 28 8 libxpc.dylib 0x000000020a01a4c4 __xpc_dictionary_look_up + 156 9 libxpc.dylib 0x000000020a01b094 _xpc_dictionary_get_array + 20 10 libdns_services.dylib 0x000000020a0b9a28 ____dnssd_client_connection_block_invoke_2 + 320 11 libxpc.dylib 0x000000020a015af0 __xpc_connection_call_event_handler + 152 12 libxpc.dylib 0x000000020a015f20 __xpc_connection_mach_event + 992 13 libdispatch.dylib 0x00000001b1657f6c __dispatch_client_callout4 + 20 14 libdispatch.dylib 0x00000001b16746ec __dispatch_mach_msg_invoke + 468 15 libdispatch.dylib 0x00000001b165f40c __dispatch_lane_serial_drain + 372 16 libdispatch.dylib 0x00000001b1675438 __dispatch_mach_invoke + 448 17 libdispatch.dylib 0x00000001b165f40c __dispatch_lane_serial_drain + 372 18 libdispatch.dylib 0x00000001b16600a4 __dispatch_lane_invoke + 384 19 libdispatch.dylib 0x00000001b166acdc __dispatch_workloop_worker_thread + 648 20 libsystem_pthread.dylib 0x0000000209fc1ddc __pthread_wqthread + 288 Exception Type: SIGSEGV SEGV_ACCERR Exception Codes: fault addr: 0x0000000000000036 Crashed Thread: 7 _

Hi team, We found that the app reported a lot of crash stacks, and the top of the stack had the libxpc library feature, but we could not find the reason. These issues have only emerged since iOS 16 and are growing, can you provide some clues or provide some solutions? Thanks Crash backtrace can be seen as follows. _ OS Version: 16.6.1 (20G81) Report Version: 104 SDK start time: 2023-09-20 18:42:40 RDM SDK Version: 2.7.27.1 RDM user id : 119902290602 RDM DeviceId: 0DB20076-F323-468F-9EEC-080B77A00E05 RDM APP KEY: 7c35edbf90 Last Exception : 0 libxpc.dylib 0x000000020a019e98 __xpc_dictionary_insert + 96 1 libxpc.dylib 0x000000020a019e84 __xpc_dictionary_insert + 76 2 libxpc.dylib 0x000000020a01b944 __xpc_dictionary_deserialize_apply + 68 3 libxpc.dylib 0x000000020a01b8cc __xpc_dictionary_apply_wire_f + 136 4 libxpc.dylib 0x000000020a018da4 __xpc_dictionary_deserialize + 108 5 libxpc.dylib 0x000000020a00cdf4 __xpc_array_deserialize + 204 6 libxpc.dylib 0x000000020a01b9ec __xpc_dictionary_unpack_value + 120 7 libxpc.dylib 0x000000020a01bbf0 __xpc_dictionary_unpack_value_and_vend + 28 8 libxpc.dylib 0x000000020a01a4c4 __xpc_dictionary_look_up + 156 9 libxpc.dylib 0x000000020a01b094 _xpc_dictionary_get_array + 20 10 libdns_services.dylib 0x000000020a0b9a28 ____dnssd_client_connection_block_invoke_2 + 320 11 libxpc.dylib 0x000000020a015af0 __xpc_connection_call_event_handler + 152 12 libxpc.dylib 0x000000020a015f20 __xpc_connection_mach_event + 992 13 libdispatch.dylib 0x00000001b1657f6c __dispatch_client_callout4 + 20 14 libdispatch.dylib 0x00000001b16746ec __dispatch_mach_msg_invoke + 468 15 libdispatch.dylib 0x00000001b165f40c __dispatch_lane_serial_drain + 372 16 libdispatch.dylib 0x00000001b1675438 __dispatch_mach_invoke + 448 17 libdispatch.dylib 0x00000001b165f40c __dispatch_lane_serial_drain + 372 18 libdispatch.dylib 0x00000001b16600a4 __dispatch_lane_invoke + 384 19 libdispatch.dylib 0x00000001b166acdc __dispatch_workloop_worker_thread + 648 20 libsystem_pthread.dylib 0x0000000209fc1ddc __pthread_wqthread + 288 Exception Type: SIGSEGV SEGV_ACCERR Exception Codes: fault addr: 0x0000000000000036 Crashed Thread: 7 _

Hello, I encountered such a problem, the scenario is like this: I have a launchctl startup daemon called xpcserver.app, which uses NSXPC to start an xpc Server. There is a Client program that links to the nsxpc service of this xpcserver.app, and when I establish the connection, I call an interface implemented by xpcserver named setName:(nsstring*)name. I was sure that my xpcserver implemented the corresponding interface, but when the client called the interface to pass the value, it triggered the error "unrecognized selector sent to instance". When I restarted the client, the call to the interface successfully implemented the function. May I ask why? Using the NSXPC started service, hope to solve, thank you