Hello, we are currently working on a plan to migrate our app suite from Developer ID binaries inside a simple pkg installer to macOS app store distribution. The reason we are using an installer is that there are multiple binaries inside that communicate via XPC and we need to install the respective launchd plist in /Library/LaunchDaemons and /Library/LaunchAgents: 1 root daemon 1 agent that has minimal UI and lives in the system menu bar 1 embedded command line utility in user agent 1 embedded FileProvider extension in user agent 1 embedded Action Extension in user agent 1 agent that only does OAuth stuff Looking through Updating helper executables from earlier versions of macOS I can install the root daemon with SMAppService.daemon(plistName:) and the OAuth helper with SMAppService.agent(plistName:). For the main application I only found SMAppService.mainApp which does not accept a property list configuration. Therefore, I have no place to put my MachServices array and so the File Provider extension, the Action Extension, and the embedded command line utility have no way to talk to the user agent. Currently, XPC is used in between these processes: user agent -> root daemon command line utility -> user agent action extension -> user agent file provider extension -> user agent user agent -> file provider extension: that already works through NSFileProviderServicing I know app-to-app communication only works through launchd for security reasons, but these applications are all part of the same app group (except the root daemon obviously). My question is what is the proper way of starting the user agent so XPC from other binaries just work ™️? Any input is much appreciated!

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!

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) }

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.

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?

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?

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

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 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?

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.

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.

We've got a non-sandboxed app with a built-in daemon that does some root-privileged things for us on occasion. We're using the newest SMAppService APIs, using NSXPCConnections for communications, and generally things work as expected. The daemon is set up to terminate when the parent app terminates. Our app also has (and uses the daemon for) a self-update feature. Once the new app is downloaded, the daemon takes over, replaces the app in-place, terminates the old app and launches the new one. However, after this update, the daemon no longer works. Any other build & launch of the app will silently fail when trying to talk to the daemon. The XPC connection can be constructed as usual, no errors, the process goes along like it should app-side, but the daemon never actually launches and never responds. I can imagine there could be a few rules being broken here with the self-update and the built-in daemon, but what would they be and how can we work within the rules?

Hello, The man page for xpcservices.plist states that: Services embedded in an application bundle will only be visible to the containing application (...) What exactly "visible" means? Doest that mean that there is a mechanism to prevent other programs than the embedding application to access the XPCService's mach port or it just means that the XPCService is not listed (e.g. launchctl list) and if attacker can guess the mach port they can access it? I'm asking to understand if there is a security gain using the -[NSXPCConnection setCodeSigningRequirement:] for embedded XPCServices.

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

Hello, I use setCodeSigningRequirement: in sandboxed XPCService and it seems that no matter what I always get errSecCSNoSuchCode[1] when the app is signed with development certificate. The same application signed with DeveloperID is fine. I use following CSR for development signed builds. identifier com.example.app and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.1] exists and certificate leaf[field.1.2.840.113635.100.6.1.12] exists But also tried to simplify to identifier com.example.app or just true. If I validated the CSR with codesign -R I get "explicit requirement satisfied". I spotted this log line: Sandbox: com.example.app(67058) deny(1) file-read-data /Users/(...)/example-app/build/arm64-mac/src/mac/app/Debug/Example App.app/Contents/MacOS/ExampleApp So I disabled the sandbox for XPCService and now everything works. But then why the DeveloperID signed build works with XPCService sandboxed? ...or does it really? :) Just for completeness the CSR which I use in production build are: identifier com.example.app and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] exists and certificate leaf[field.1.2.840.113635.100.6.1.13] exists and certificate leaf[subject.OU] = EXAMPLE

hi all. I subscribe the notify write event, every time I recieve a notify write event message i will send log data and reply block(didn't do nothing) with async method to host app(Objc XPC API).host app will reply immediately once it recieves data. after a while my sysext crashed, then I checked system log find the log below. launchd: exited with exit reason (namespace: 30 code: 0xc40000000004aaaa) - (unknown reason) is it because of exceeding the maximum limit of xpc's block queue length, or too many memory allocation, or... by the way, host app didn't crash. how this happened exactly? how could i solve it?

How do you send an NSURL representing a new file, as returned from an NSSavePanel, to an XPC service such that the service is granted permission to create the file? I can successfully pass an NSURL to the XPC process if the NSURL represents an existing file. This is documented in Apple's Documentation: Share file access between processes with URL bookmarks This involves creating bookmark date while passing 0 in as the options. However, if you try to create bookmark data for an NSURL that represents a file that is not yet created, you do not get any bookmark data back and an error is returned instead: Error Domain=NSCocoaErrorDomain Code=260 "The file couldn’t be opened because it doesn’t exist." Simply passing the file path to the XPC process, by way of: xpc_dictionary_set_string(message, "file_path", url.fileSystemRepresentation); Does not grant the XPC create/write permissions. Is there an API or trick I'm missing? Note that the user should be allowed to save and create new files anywhere of their choosing, thus restricting URLs to only those within a group or container shared between the app and service isn't really viable. Using the latest of everything on macOS with the xpc_session API...

2024-06-04 15:17:59.618853+0100 ProxyAgent[20233:29237510] [xpc.exceptions] <NSXPCConnection: 0x60000331cb40> connection from pid 20227 on anonymousListener or serviceListener: Exception caught during decoding of received selector newFlowWithIdentifier:to:type:metadata:socket:, dropping incoming message. Exception: Exception while decoding argument 4 (#6 of invocation): <NSInvocation: 0x600001778780> return value: {v} void target: {@} 0x0 selector: {:} null argument 2: {@} 0x6000017787c0 argument 3: {@} 0x60000002d170 argument 4: {q} 1 argument 5: {@} 0x600001746600 argument 6: {@} 0x0 Exception: decodeObjectForKey: Object of class "NSFileHandle" returned nil from -initWithCoder: while being decoded for key <no key> The extension is in Swift; the recipient is in ObjC (wheeeeee). Based on the extension's logging, the FileHandle is not nil. I am trying to pass a FileHandle based on a socketpair up to the user-land code. The sockets are created happily. Any ideas what's going wrong here?

(Updated) See replies below.