XPC is the preferred inter-process communication (IPC) mechanism on Apple platforms. XPC has three APIs: The high-level NSXPCConnection API, for Objective-C and Swift The low-level Swift API, introduced with macOS 14 The low-level C API, which, while callable from all languages, works best with C-based languages General: DevForums tag: XPC Creating XPC services documentation NSXPCConnection class documentation Low-level API documentation XPC has extensive man pages — For the low-level API, start with the xpc man page; this is the original source for the XPC C API documentation and still contains titbits that you can’t find elsewhere. Also read the xpcservice.plist man page, which documents the property list format used by XPC services. Daemons and Services Programming Guide archived documentation WWDC 2012 Session 241 Cocoa Interprocess Communication with XPC — This is no longer available from the Apple Developer website )-: Technote 2083 Daemons and Agents — It hasn’t been updated in… well… decades, but it’s still remarkably relevant. TN3113 Testing and Debugging XPC Code With an Anonymous Listener XPC and App-to-App Communication DevForums post Validating Signature Of XPC Process DevForums post Related tags include: Inter-process communication, for other IPC mechanisms Service Management, for installing and uninstalling Service Management login items, launchd agents, and launchd daemons Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I'm looking into a newer XPC API available starting with macOS 14. Although it's declared as a low-level API I can't figure it how to specify code signing requirement using XPCListener and XPCSession. How do I connect it with xpc_listener_set_peer_code_signing_requirement and xpc_connection_set_peer_code_signing_requirement which require xpc_listener_t and xpc_connection_t respectively? Foundation XPC is declared as a high-level API and provides easy ways to specify code signing requirements on both ends of xpc. I'm confused with all these XPC APIs and their future: Newer really high-level XPCListener and XPCSession API (in low-level framework???) Low-level xpc_listener_t & xpc_connection_t -like API. Is it being replaced by newer XPCListener and XPCSession? How is it related to High-level Foundation XPC? Are NSXPCListener and NSXPCConnection going to be deprecated and replaced by XPCListener and XPCSession??

We use as content filter in our app to monitor flows, we gather data about the flow and block flows deemed suspicious. Our content filter is activated/deactivated by a UI app but the flows are reported via XPC to a separate daemon process for analysis. As of macOS 15, we are seeing cases where flows are missing or flows are not received at all by the content filter. The behaviour is not consistent, some devices seem to receive flows normally but others don't. It appears Intel devices are much less prone to showing the problem, whereas Arm devices routinely exhibit missing flows. On macOS 14 or earlier, there is no sign of missing flows. Testing on earlier beta versions of macOS 15 did not appear to show the problem, however I can't rule out if issue was present but it wasn't spotted. Experimenting with simple examples of using a content filter (e.g. QNE2FilterMac) does not appear to reproduce the issue. Questions, What has changed between macOS 14 and 15 that could be the cause of the lack of flows? Is our approach to using an app activated content filter reporting to a daemon connected via XPC unsupported?

I was experimenting with Service Management API and Xcode project from https://developer.apple.com/documentation/servicemanagement/updating-your-app-package-installer-to-use-the-new-service-management-api and faced some issues with the API. I replaced agent with XPC service and tried to re-register it. Use case is a new app package installation with a newer service binary. In order to get the running service restarted with the new binary it's required to unregister old version and register new one. Otherwise the old version would be still running after app upgrade. The problem is that register fails with "Operation not permitted" error after running unregister which seems to work fine. Experiments with some delays (500ms) between unregister and register seem to help but it's a not a good solution to work around the problem. I'm using open func unregister() async throws with description: The completion handler will be invoked after the running process has been killed if successful or will be invoked whenever an error occurs. After the completion handler has been invoked it is safe to re-register the service. Sample output with no 500ms sleep between unregister and register calls: /Library/Application\ Support/YourDeveloperName/SMAppServiceSampleCode.app/Contents/MacOS/SMAppServiceSampleCode unregister && /Library/Application\ Support/YourDeveloperName/SMAppServiceSampleCode.app/Contents/MacOS/SMAppServiceSampleCode register Successfully unregistered LaunchDaemon(com.xpc.example.service.plist) Unable to register LaunchDaemon(com.xpc.example.service.plist): Error Domain=SMAppServiceErrorDomain Code=1 "Operation not permitted" UserInfo={NSLocalizedFailureReason=Operation not permitted} In fact it doesn't seem to be safe to re-register. Any explanation would much appreciated! ===================================================== Side issue #2: I tried to add a similar helper executable as in the original project with register/unregister and put it inside the same app bundle but at a different location like Contents/Helpers/ folder instead of Contents/MacOS. And it always fails with this error: Error Domain=SMAppServiceErrorDomain Code=3 "Codesigning failure loading plist: com.okta.service.osquery code: -67028" UserInfo={NSLocalizedFailureReason=Codesigning failure loading plist: com.okta.service.osquery code: -67028} When I moved the helper binary to Contents/MacOS/ folder along with the main app executable it starts working fine again. Other folders like Resources/XPCServices also don't work. Is it a hard requirement for an executable to be located inside main Contents/MacOS folder in order to be able to call SMAppService register/unregister APIs? I haven't found any documentation regarding this requirement. Thanks, Pavel

I created a macOS app, added an XPC service target, and also added a source editor extension. in The source editor extension‘s perform function. It doesn't work - (void)performCommandWithInvocation:(XCSourceEditorCommandInvocation *)invocation completionHandler:(void (^)(NSError * _Nullable nilOrError))completionHandler { self.xpcConnect = [[NSXPCConnection alloc] initWithServiceName:@"test.TestNewXPCApp.NewXPC"]; NSXPCInterface *interface = [NSXPCInterface interfaceWithProtocol:@protocol(NewXPCProtocol)]; self.xpcConnect.remoteObjectInterface = interface; [self.xpcConnect resume]; [[self.xpcConnect remoteObjectProxy] performCalculationWithNumber:@231 andNumber:@119 withReply:^(NSNumber *reply) { // We have received a response. NSLog(@"ui success%@", reply); }]; But In ViewControler.m, executing the same code , it can work. So why is it possible to connect to the XPC service from within the macOS app, but not from the source editor extension?

There does not seem to be a way to code sign a PAM module so that an XPC service can verify the signature with setCodeSigningRequirement. There should be a way to build a PAM module (dynamic Library ) so it can be code signed. Put in a bundle and code signing the bundle does not work .

When I try to launch my own Java app, I get the following error message. xpcproxy exited due to OS_REASON_CODESIGNING | Launch Constraint Violation, error info: c[5]p[1]m[1]e[0], (Constraint not matched) launch type 3, failure proc [vc: 1]: /bin/bash As far as I know, the failing process path is /bin/bash. This issue is only happening on macOS Sequoia. The Java app works without any issue on MacOS Sonoma or any previous macOS versions. I did not make any changes, including launch constraints or any other settings. After updating to macOS Sequoia, I started getting this error and can no longer launch my app. Thank you so much.

I've developed a Endpoint Security system extension, which will be installed in a container APP. I use XPC to send message from container APP to the ES client, it works fine. I have developed an Endpoint Security system extension that will be installed in a container app. I utilize XPC to send messages from the container app to the ES client, and it functions properly. However, when I attempt to send messages from the ES client to the container app, it always displays an error: 'Couldn’t communicate with a helper application.'. I have removed the sandbox capability of the container app and also employed the same app group for both the ES client and the container app. When an XPC client is connected, I use the following code in the ES client to establish two-way communication. - (BOOL)listener:(NSXPCListener *)listener shouldAcceptNewConnection:(NSXPCConnection *)newConnection { newConnection.exportedInterface = [NSXPCInterface interfaceWithProtocol:@protocol(NXFileGuardXPCProtocol)]; NXFileGuardXPCService *xpcService = [NXFileGuardXPCService sharedInstance]; newConnection.exportedObject = xpcService; // To APP container client (As remote interface) newConnection.remoteObjectInterface = [NSXPCInterface interfaceWithProtocol:@protocol(NXFileGuardXPCClientProtocol)]; [newConnection activate]; self.containerAPPConnection = newConnection; return YES; } But it always fails. How can I deal with this error?

Hello, I run into an issue on Monterey (12.7.5). I have a bundled XPC service in my application which is displaying some stuff and playin sounds via NSSound. I had a problem with playback due to service priority, so I use the trick with a reply block where I send a reply block to the service and basically just retain it and never call it. This worked fine so far, but we have users, predominantly on Monterey, who are having a problem with sound playback. It's choppy and distorted when their machine is under load (where "load" often just means playing a video on YouTube in Chrome). Is there anything else I can do to get the proper priority for my xpc service so I can avoid distorted sound? Additionally the service type is Application and RunLoopType is NSRunLoop with JoinExistingSession set to true. The QoS level of main queue is 0x21 (user interactive) and I'm calling all the NSSound APIs on main queue.

I recently update my ionic app to ionic angular 7. I'm having this crash that does not happen in the same way, neither in the same place. Aside from needed some entitlements that I've already requested the app is crashing all the time. This is the error. ⚡️ TO JS {"value":"en"} 2024-09-24 15:43:56.097126+0200 App[33392:5520337] [Process] 0x10d003260 - [PID=33408] WebProcessProxy::didClose: (web process 0 crash) 2024-09-24 15:43:56.097185+0200 App[33392:5520337] [Process] 0x10d003260 - [PID=33408] WebProcessProxy::processDidTerminateOrFailedToLaunch: reason=Crash 2024-09-24 15:43:56.097270+0200 App[33392:5520337] [ProcessSuspension] 0x10c020720 - ProcessAssertion: Failed to acquire RBS Background assertion 'XPCConnectionTerminationWatchdog' for process because PID 0 is invalid 2024-09-24 15:43:56.097368+0200 App[33392:5521826] [ProcessSuspension] 0x10c020720 - ProcessAssertion::acquireSync Failed to acquire RBS assertion 'XPCConnectionTerminationWatchdog' for process with PID=0, error: (null) 2024-09-24 15:43:56.098184+0200 App[33392:5520337] [Process] 0x142832618 - [pageProxyID=8, webPageID=9, PID=33408] WebPageProxy::processDidTerminate: (pid 33408), reason=Crash 2024-09-24 15:43:56.101821+0200 App[33392:5520337] [Loading] 0x142832618 - [pageProxyID=8, webPageID=9, PID=33408] WebPageProxy::dispatchProcessDidTerminate: reason=Crash 2024-09-24 15:43:56.117084+0200 App[33392:5522124] [com.apple.VisionKit.processing] Error processing request from MAD on result: Error Domain=NSOSStatusErrorDomain Code=-128 "Request was canceled" UserInfo={NSLocalizedDescription=Request was canceled} request: <VKCImageAnalyzerRequest: 0x2830d0690> requestID: 6 madRequestID: 6 cancelled: YES 2024-09-24 15:43:56.245502+0200 App[33392:5520337] [Process] 0x10c07c380 - GPUProcessProxy::gpuProcessExited: reason=IdleExit 2024-09-24 15:43:56.245552+0200 App[33392:5520337] [Process] 0x10d002ce0 - [PID=33412] WebProcessProxy::gpuProcessExited: reason=IdleExit 2024-09-24 15:43:57.682680+0200 App[33392:5520337] Could not signal service com.apple.WebKit.WebContent: 113: Could not find specified service 2024-09-24 15:44:04.249892+0200 App[33392:5520337] Could not signal service com.apple.WebKit.WebContent: 113: Could not find specified service 2024-09-24 15:44:12.223579+0200 App[33392:5520337] Could not signal service com.apple.WebKit.WebContent: 113: Could not find specified service 2024-09-24 15:44:26.098426+0200 App[33392:5520337] Could not signal service com.apple.WebKit.WebContent: 113: Could not find specified service 2024-09-24 15:44:59.812245+0200 App[33392:5522961] [MADService] Client XPC connection invalidated

Hi Everyone, I would appreciate your help with the topic mentioned above. I'm seeking a solution for the issue I linked below. https://discussions.apple.com/thread/255668660?sortBy=best Apple Support said I could get a faster response. I've also submitted the issue to Apple Support, and they said it's currently with an Apple Engineer, but things are moving a bit slowly there. I'm writing the similar explanation I wrote on the discussion forum here as well. It's been months, and I hope we can get a result here: **Here is the problem: ** I've noticed that the "CursorUIViewService" process in Activity Monitor is becoming 'not responding' and causing significant lag on my MacBook Air (M3), especially when typing and switching between upper and lower case letters. It appears this process also controls the blue caps-lock indicator, which stops working when the process is unresponsive. This issue seems to cause the lag, and currently, it is using about 170MB of RAM. Additionally, the "com.apple.hiservices-xpcservice" process also becomes unresponsive , though it usually doesn't exceed 3.5MB of RAM. Actually, this process becomes 'not responding' much more frequently compared to the CursorUIViewService process. The possibility that it might be related to CursorUIViewService pushed me to research this issue as well. I can see that there have been complaints about this process for years, but it seems no solution is being produced. By the way, I've tried everything. I did a clean install, ran diagnostics, performed first aid, and still encountered the problem. Has anyone else experienced this issue or found a solution? As an update, I would like to inform you that the "com.apple.hiservices-xpcservice" process is still experiencing not responding issues with macOS Sequoia (15.0). However, because "cursoruiviewservice" was causing problems less often on Sonoma, I can't say the issue is completely resolved just yet; I need to monitor the situation. Thank you!

I have an Electron app built for macOS, and it was distributed via 'Developer ID' for years, it worked well and I was able to access the photos in the system Photos library. Surely I already have the 'NSPhotoLibraryUsageDescription' key in Info.plist. Recently we are trying to publish this app to Mac App Store, so I have to turn on the sandbox, after that the app starts giving XPC errors while accessing the Photos library. The errors look like: PHAuthorizationStatus: Authorized CoreData: XPC: sendMessage: failed #0 CoreData: XPC: Unable to sendMessage: to server ... CoreData: XPC: sendMessage: failed #7 CoreData: XPC: Unable to connect to server with options { NSPersistentHistoryTrackingKey = 1; NSXPCStoreServerEndpointFactory = "<PLXPCPhotoLibraryStoreEndpointFactory: 0x7fc67e8af370>"; skipModelCheck = 1; } CoreData: XPC: Unable to load metadata: Error Domain=NSCocoaErrorDomain Code=134060 "A Core Data error occurred." UserInfo={Problem=Unable to send to server; failed after 8 attempts.} CoreData: fault: Unable to create token NSXPCConnection. NSXPCStoreServerEndpointFactory 0x7fc67e8af370 -newEndpoint returned nil CoreData: error: Failed to create NSXPCConnection It seems the app could detect the current PHAuthorizationStatus which is Authorized, but it can't fetch the photos from the Photos library (using PhotoKit). I learned from here that I could look for errors from the sandboxd daemon, so I did that, here is what I saw: Sandbox: Picture Keeper(32625) deny(1) mach-lookup com.apple.photos.service Violation: deny(1) mach-lookup com.apple.photos.service Process: Picture Keeper [32625] Path: /Applications/Picture Keeper.app/Contents/MacOS/Picture Keeper Load Address: 0x103bd3000 Identifier: com.simplifieditproducts.picturekeepermas Version: 4575 (4.5.75) Code Type: x86_64 (Native) Parent Process: Picture Keeper [1] Responsible: /Applications/Picture Keeper.app/Contents/MacOS/Picture Keeper User ID: 501 Date/Time: 2024-08-26 16:16:14.645 EDT OS Version: macOS 14.5 (23F79) Release Type: User Report Version: 8 MetaData: {"process_path":["Users","Kevin","Projects","Electron","picturekeeper-electron","dist","picturekeeper","mas-dev","Picture Keeper.app","Contents","MacOS","Picture Keeper"],"apple-internal":false,"primary-filter":"global-name","policy-description":"Sandbox","flags":5,"platform-policy":false,"build":"macOS 14.5 (23F79)","process-path":"\/Applications\/Picture Keeper.app\/Contents\/MacOS\/Picture Keeper","responsible-process-path":"\/Applications\/Picture Keeper.app\/Contents\/MacOS\/Picture Keeper","primary-filter-value":"com.apple.photos.service","platform_binary":"no","responsible-process-signing-id":"com.simplifieditproducts.picturekeepermas","hardware":"Mac","target":"com.apple.photos.service","action":"deny","mach_namespace":1,"checker-pid":1,"container":"\/Users\/Kevin\/Library\/Containers\/com.simplifieditproducts.picturekeepermas\/Data","binary-in-trust-cache":false,"team-id":"LU744924UY","process":"Picture Keeper","global-name":"com.apple.photos.service","platform-binary":false,"pid":32625,"summary":"deny(1) mach-lookup com.apple.photos.service","checker":"launchd","responsible-process-team-id":"xxxxx","operation":"mach-lookup","normalized_target":["com.apple.photos.service"],"errno":1,"uid":501,"profile-flags":0,"profile-in-collection":false,"sandbox_checker":"launchd","signing-id":"com.simplifieditproducts.picturekeepermas","release-type":"User"} I believe I already have the necessary entitlements for the Photos library, see: codesign -d --entitlements - /Applications/Picture\ Keeper.app/Contents/MacOS/Picture\ Keeper [Dict] [Key] com.apple.application-identifier [Value] [String] xxxx.com.simplifieditproducts.picturekeepermas [Key] com.apple.developer.team-identifier [Value] [String] xxxx [Key] com.apple.security.app-sandbox [Value] [Bool] true [Key] com.apple.security.application-groups [Value] [Array] [String] xxxx.com.simplifieditproducts.picturekeepermas [Key] com.apple.security.assets.movies.read-only [Value] [Bool] true [Key] com.apple.security.assets.music.read-only [Value] [Bool] true [Key] com.apple.security.assets.pictures.read-write [Value] [Bool] true [Key] com.apple.security.cs.allow-dyld-environment-variables [Value] [Bool] true [Key] com.apple.security.cs.allow-jit [Value] [Bool] true [Key] com.apple.security.cs.allow-unsigned-executable-memory [Value] [Bool] true [Key] com.apple.security.cs.disable-executable-page-protection [Value] [Bool] true [Key] com.apple.security.cs.disable-library-validation [Value] [Bool] true [Key] com.apple.security.device.usb [Value] [Bool] true [Key] com.apple.security.files.bookmarks.app-scope [Value] [Bool] true [Key] com.apple.security.files.bookmarks.document-scope [Value] [Bool] true [Key] com.apple.security.files.downloads.read-only [Value] [Bool] true [Key] com.apple.security.files.user-selected.read-write [Value] [Bool] true [Key] com.apple.security.network.client [Value] [Bool] true [Key] com.apple.security.network.server [Value] [Bool] true [Key] com.apple.security.personal-information.location [Value] [Bool] true [Key] com.apple.security.personal-information.photos-library [Value] [Bool] true By the way, the Photos library related code was built into a .node file (which is a dylib), and it will be loaded by the main executable during runtime. Anything I missed? Thank you!

After the XPC Updates from last year I am trying to understand what is possible with XPC on iOS. The documentation for XPCSession states it is available, but none of its initializers is. So how is one supposed to use it?

We maintain a device driver for macOS. This consists of a bunch of components including a Launch Agent, a (Cocoa/AppKit) status bar item app, and a "main" windowed UI app. These all communicate with each other via XPC using the "low level" XPC APIs (libxpc). The launch agent registers a named Mach XPC service, and the two apps connect to it when they launch. Last year, we had an overhaul of the main UI app as we wanted to add a bunch of features. In the process we decided to switch it from Cocoa/AppKit to Mac Catalyst/UIKit as we were also contemplating porting the driver to iPadOS in future; plus, UIKit is a little simpler and I'm not a great UI programmer, so any simplification is welcome. This has worked OK so far, but in our attempt to upgrade our build toolchain from Xcode 15.2 to Xcode 15.4 we found that the Catalyst app would no longer build. Apparently the xpc_connection_create_mach_service() and xpc_connection_set_peer_code_signing_requirement() functions are no longer available as of the Mac Catalyst SDK included with Xcode 15.3. This makes it impossible for the app to connect to the launch agent's XPC service. A few things to note: These functions were never deprecated, so we did not have their impending removal on our radar. It seems they actually used to be available in the iOS SDK and were removed from that, so Mac Catalyst is effectively collateral damage. I don't think these would ever have been usable in apps on the iOS App Store, so perhaps they were removed from the iOS SDK ahead of support for notarised iOS app distribution. So it looks like they might have been removed from Mac Catalyst SDK by accident? I therefore filed a bug about this - FB13929309 - about 6 weeks ago. Reinstating the functions for Mac Catalyst would seem like a very straightforward fix, but I've not had a hint of feedback on the report. I guess my forum question comes down to this: Is Mac Catalyst considered a platform for building macOS apps in its own right? Or are we "holding it wrong" and should we only treat it as a way of tweaking Mac ports of iOS/iPad-first apps? Should we expect APIs to disappear from the Mac Catalyst SDK with zero notice? We can still build with Xcode 15.2 for the moment, and the app built this way runs fine up to and including the macOS 15 beta. But thanks to the limited forward and backward compatibility schedule for Xcode we can't stay on old Xcode for long We're also planning to make some feature changes to the app in the near future, and I don't want to be investing in an app built on a platform with no future. I'd rather port the app back to Cocoa/AppKit before adding features if that's the case.

Using NSFileManager's getFileProviderServicesForItemAtURL method, I can list services made available by a file provider for a given item from an app unrelated to the file provider, obtain a handle to the proxy object and cast that object to the target protocol. However, attempts to invoke the protocol yield: "The connection to service named com.apple.mobile.usermanagerd.xpc was invalidated: failed at lookup with error 159 - Sandbox restriction." The documentation for the supportedServiceSourcesForItemIdentifier method implemented by the extension suggests only the app containing the extension can exercise the service but the documentation for getFileProviderServicesForItemAtURL does not. Should I be able to access a service from a file provider extension from an unrelated app? If so, how can the sandbox restriction be addressed?

I'm developing a system that uses an ES extension to control user file openings on Mac. When a user tries to open a file, the ES extension can either allow or deny the user from opening it. However, the policy for allowing/denying users to open files is managed by my normal Mac app. Therefore, the ES extension needs to proactively communicate with the normal app. Initially, I wanted to create an XPC service in my regular app, but according to the documentation, XPC services are managed by launchd and cannot be created by regular apps. So if I want my ES extension to communicate with the regular app proactively, what IPC method can I use?

I’m working on a launch daemon. I’m in the process of adding setCodeSigningRequirement to both sides of the connection, starting with the XPC service. I’ve already made it so that the service calls setCodeSigningRequirement on a new connection passed to the listener method of NSXPCListenerDelegate. It works and the connection does get invalidated. The launch daemon logs stdout and stderr to a file already. So I figured that if a connection gets invalidated because of a code signing failure, it’d be nice to NSLog this to make it easier for users to debug what’s going on, without forcing them to use Console.app. The docs for setCodeSigningRequirement include an example of how to capture this error on the client side, when the client calls that method. What I cannot figure out is how to capture this error on the side of the XPC service. I could use setInvalidationHandler, but the problem with it is that a connection can be invalidated for a myriad of reasons and the handler doesn’t know what happened. Is there perhaps an equivalent of remoteObjectProxyWithErrorHandler but for the service side of the connection?

Hi, my app ScreenFloat can capture screenshots and record the screen (along with system- and microphone audio). It does this in an XPC service. On macOS Sequoia b1-3, recording does not work anymore (although permissions are granted to the app in System Preferences > Privacy & Security). Instead, I keep getting an error that my XPC service can access this computer's screen and audio. (of course, that's the point!) First of all, the screen is locked when the warning appears, clicks anywhere on the screen are not recognized. I have to hit Escape (or wait about a minute, at which point it resolves itself), to be able to click anywhere. Clicking on Continue To Allow doesn't do anything, either. The warning just re-appears every time. Do I need to add a new entitlement to my main app or the XPC service, or any new NSUsage strings to the InfoPlist.strings? How can I resolve this? Thank you, Matthias

I have a project with two processes: a UI app (non root) and a system extension (root). The XPC communication between them is functioning correctly. Now, I want to add another process for a different task. I created a new XPC target (HelperProcess) in Xcode and set up an XPC connection between the UI process and this new HelperProcess, which works fine. However, when I try to establish an XPC connection between the HelperProcess and the system extension, it fails. I used the same steps I did to set up the XPC connection between the HelperProcess and the UI process. Specifically, I am using initWithServiceName: to identify the process for communication, but this approach only fails for the system extension and not for the UI part.

I'm trying to use XPC communicate between a command line tool (launched from Terminal) and a macOS application. My code currently works when the app is launched from Xcode, but not if I launch the built app from the command line (open path-to-foo.app) or if I try and distribute the packaged application (via "Development" distribution). Notably, the XPC works if the command line tool is launched from the terminal as long as the app itself is launched from Xcode. I publish the XPC service using NSXPCListener(machServiceName: <team-identifier>.com.example.my-app.service) and connect to it using NSXPCConnection(machServiceName: machServiceName). Both my command line tool and my main app identical "app group" entitlements for $(TeamIdentifierPrefix)com.example.my-app and I verified the team identifier substitution was correct in both the app and command line tool after doing distributing for "App Store", exporting, unpacking the pkg and running codesign as described here: https://developer.apple.com/documentation/xcode/embedding-a-helper-tool-in-a-sandboxed-app

We have a product which uses a Network Extension (a socket filter and a packet content filter). The application contains the network extension, as well as an un-sandboxed LaunchDaemon which connects to the service at the NEMachServiceName. Occasionally, usually after an upgrade where the system extension is swapped for the new version, our un-sandboxed process isn't able to contact the network extension. From the logging, we receive the following XPC error (libxpc.dylib) [com.apple.xpc:connection] [0x7fd6d0307f40] failed to do a bootstrap look-up: xpc_error=[3: No such process] in the unsandboxed process. Eventually, we receive an invalidated callback on the XPC connection with the error Couldn’t communicate with a helper application.. We have confirmed that an appropriate service is running via the launchctl command, and the network extension process appears to have initialised correctly. We don't see any indication of a received connection at the Network Extension process however (probably not surprising given the error). Once a system enters this state, repeated attempts to connect are unsuccessful and continue to produce the same error. We've also confirmed that there are no XPC codec exceptions apparent that might cause the connection to fail. I'm at a bit of a loss to explain why this failure might be occurring, other than a problem in the bootstrap/launchd being able to find the appropriate service. Is there possibly some problem with unsandboxed processes accessing the sandboxed network extension via XPC? They are both provisioned in an app group together. Is there possibly some issue where attempting to connect at a critical point during network extension installation causes it to become inaccessible? We've observed this specifically on macOS 14.5 (23F79), however this is something we've noticed on other versions of macOS and our code. The problem isn't systematic, and systems end up in this state only occasionally. We do seem to find some customers have more instances of this problems than others, but we haven't been successful at teasing out any common thread that might explain why.