I have followed this post for creating a Launch Agent that provides an XPC service on macOS using Swift- post link - https://rderik.com/blog/creating-a-launch-agent-that-provides-an-xpc-service-on-macos/ In the swift code the interface of the XPC service is defined by protocols which makes the code nice and neat. I want to implement the XPC service using C APIs for XPC, and C APIs send and receive messages using dictionaries, which need manual handling with conditional statements. I want to know if its possible to go with the protocol based approach with C APIs.

In the macOS 14.0 SDK, environment and library constraints were introduced, which made defense against common attack vectors relatively simple (especially with the LightWeightCodeRequirements framework added in 14.4). Now, the application I'm working on must support macOS 13.0 too, so I was looking into alternatives that do work for those operating systems as well. What I found myself is that the SecCode/SecStaticCode APIs in the Security Framework do offer very similar fashion checks as the LightWeightCodeRequirements framework does: SecCodeCopySigningInformation can return values like signing identifier, team identifier, code requirement string and so on. SecStaticCodeCreateWithPath can return a SecStaticCode object to an executable/app bundle on the file system. Let's say, I would want to protect myself against launchd executable swap. From macOS 14.0 onward, I would use a Spawn Constraint for this, directly in the launchd.plist file. Before macOS 14.0, I would create a SecStaticCode object for the executable path found in the launchd.plist, and then examine its SecCodeCopySigningInformation dictionary. If the expectations are met, only then would I execute the launchd.plist-defined executable or connect to it via XPC. Are these two equivalent? If not, what are the differences?

I have several processes maintaining NSXPConnection to an XPC service. The connections are bi-directional. Each side service and clients) of the connection exports an object, and an XPCInterface. The @protocols are different - to the service, and from the service to clients. So long as all the "clients" fully implement their "call-back" @protocol, there's no problem. All works fine. However - If a client does NOT implement a method in the "call back protocol", or completely neglects to export an object, or interface - and the service attempts to call back using the nonexistent method -- the XPC connection invalidates immediately. So far - expected behaviour. However, if I want the service to behave to the client a little like a "delegate" style -- and check first whether the client "respondsToSelector" or even - supports an interface BEFORE calling it, then this doesn't work. When my XPC service tries the following on a client connection: if (xpcConnection.remoteObjectInterface == nil) os_log_error(myXPCLog, "client has no remote interface); the condition is never met - i.e. the "remoteObjectInterface is never nil even when the client does NOT configure its NSXPCConnection with any incoming NSXPCInterface, and does not set an "exportedObject" Furthermore, the next check: if ([proxy respondsToSelector:@selector(downloadFiltersForCustomer:withReply:)]) { } will not only fail - but will drop the connection. The client side gets the invalidation with the following error: <NSXPCConnection: 0x600000b20000> connection to service with pid 2477 named com.proofpoint.ecd: received an undecodable message for proxy 1 (no exported object to receive message). Dropping message. I guess the "undecidable message" is the respondsToSelector - because the code doesn't get to attempt anything else afterwards, the connection drops. Is there a way to do this check "quietly", or suffering only "interruption", but without losing the connection,

I'm attempting to install a NetworkExtension as a system extension, using the OSSystemExtensionManager.shared.submitRequest(request) API call. I can see from console logs and systemextensionsctl that my system extension is getting installed, but the OSSystemExtensionRequestDelegate I attach to the request never gets a callback. In the console logs I see: com.apple.sx default 14:13:25.811827+0400 sysextd activateDecision found entry to replace: com.coder.Coder-Desktop.VPN, BundleVersion(CFBundleShortVersionString: "1.0", CFBundleVersion: "1") default 14:13:25.811888+0400 sysextd initial activation decision: requestAppReplaceAction(<sysextd.Extension: 0xa94030100>) com.apple.sx default 14:13:25.811928+0400 sysextd notifying client of activation conflict com.apple.xpc default 14:13:25.812156+0400 Coder Desktop [0x154f2d5b0] invalidated because the current process cancelled the connection by calling xpc_connection_cancel() com.apple.xpc default 14:13:25.813924+0400 sysextd [0xa941d4280] invalidated because the client process (pid 2599) either cancelled the connection or exited com.apple.sx default 14:13:25.814027+0400 sysextd client connection (pid 2599) invalidated It appears that something within my app process is cancelling the XPC connection to sysextd, but I'm certainly not calling it from within my code. Presumably something within the OSSystemExtension* APIs are cancelling the connection but I don't know why. It seems to be happening very quickly (within a few hundred ms) after sending the request, and before sysextd can reply. What could cause this connection to be canceled?

Hello, I'm developing a Mac application that uses a network extension. I'm trying to implement XPC to pass data between my main app and system extension and I'm using the SimpleFirewall demo app as a guide to do this. One thing I can't understand is how the ViewController in the SimpleFirewall main app has access to the class IPCConnection in the SimpleFirewallExtension without it being public and without SimpleFirewallExtension being imported in ViewController.

hello everyone On iOS18.0+, app crashed at BSXPCCnx:com.apple.backboard.hid-services.xpc (BSCnx:client:BKHIDEventDeliveryObserver) when app enter background sometimes crash stacktrace: Crashed: BSXPCCnx:com.apple.backboard.hid-services.xpc (BSCnx:client:BKHIDEventDeliveryObserver) 0 libsystem_pthread.dylib 0x4078 pthread_mutex_lock + 12 1 ilink_live 0xbd884 (缺少 UUID 973fe6c5058c35bda98679b0c8aa0129) 2 ilink_live 0xb75fc (缺少 UUID 973fe6c5058c35bda98679b0c8aa0129) 3 libsystem_c.dylib 0x23190 __cxa_finalize_ranges + 492 4 libsystem_c.dylib 0x22f8c exit + 32 5 BackBoardServices 0x31b78 -[BKSHIDEventObserver init] + 98 6 BoardServices 0x1dc78 __31-[BSServiceConnection activate]_block_invoke.182 + 128 7 BoardServices 0x1beb4 __61-[BSXPCServiceConnectionEventHandler _connectionInvalidated:]_block_invoke + 196 8 BoardServices 0x4a58 BSXPCServiceConnectionExecuteCallOut + 240 9 BoardServices 0x1d6e8 -[BSXPCServiceConnectionEventHandler _connectionInvalidated:] + 180 10 libdispatch.dylib 0x2248 _dispatch_call_block_and_release + 32 11 libdispatch.dylib 0x3fa8 _dispatch_client_callout + 20 12 libdispatch.dylib 0xb5cc _dispatch_lane_serial_drain + 768 13 libdispatch.dylib 0xc158 _dispatch_lane_invoke + 432 14 libdispatch.dylib 0xb42c _dispatch_lane_serial_drain + 352 15 libdispatch.dylib 0xc158 _dispatch_lane_invoke + 432 16 libdispatch.dylib 0x1738c _dispatch_root_queue_drain_deferred_wlh + 288 17 libdispatch.dylib 0x16bd8 _dispatch_workloop_worker_thread + 540 18 libsystem_pthread.dylib 0x3680 _pthread_wqthread + 288 19 libsystem_pthread.dylib 0x1474 start_wqthread + 8 when crash happened ,most of time app recieved CBManagerStateResetting and CBManagerStateUnsupported event i would appreciate any insights or recommendations on how to resolve this issue thx crash_stacktrace.txt