The tricky part here is that, once you start messing around with code running as root, there are multiple TCC databases to contend with, namely the one for your user account and the one for the system as a whole. That complicates matters. Thanks for the insight. I didn't know that! Out of curiosity: would a sudo tccutil reset All com.mycompany.myapp reset the permissions for the app for the root user? So, anyway, lemme clarify your actual setup. It sounds like you’re: Using an IOHIDManager to discover HID devices. That vends you various IOHIDDevice objects. You choose one and call IOHIDDeviceOpen on it. Is that right? I'm doing it a bit differently: Using IOServiceAddMatchingNotification() to look for IOKit services of IOHIDDevice class. Match the properties of the IOKit services/devices I receive in the callback with the properties in the callback. And if it fulfills my criteria, proceed to the next step. Use IORegistryEntryGetRegistryEntryID() to get the registry entry ID for the IOKit service of the HID device Send that IOKit RegistryEntryID over XPC to my service running as root. In the service running as root, use IOServiceGetMatchingServices(kIOMainPortDefault, IORegistryEntryIDMatching(entryID), …) to get the IOKit service for the HID device I want to open Use IOHIDDeviceCreate(kCFAllocatorDefault, ioService) to get the IOHIDDeviceRef for the IOKit service Pass that to IOHIDDeviceOpen() to open the device: via IOHIDDeviceOpen(hidDevice, kIOHIDOptionsTypeSeizeDevice) Are you passing in kIOHIDOptionsTypeSeizeDevice? Yes I do. If it helps, I can provide a source code example via Feedback Assistant that's ready to run after adjusting the Team IDs.

Thanks for the suggestions and explanations! I wasn't able to use VMs for testing here as I couldn't find a way to make a HID device connected to the host "owned" by the guest. So instead I used two Macs never used for development. On the first, I first ran the version using SMJobBless, then the version using SMAppService. On the second, I ran them in the opposite order (SMAppService first, SMJobBlesss second). I got results consistent with my development Mac on both (SMJobBless works, SMAppService version call to IOHIDDeviceOpen fails with kIOReturnNotPermitted). Regarding TCC: during debugging this earlier on my development Mac, I also tried resetting TCC for my app via tccutil reset All com.mycompany.myapp (and then re-assigning it the Accessibility permissions through System Settings), but this also didn't have an effect on the outcome.

I've since converted the project to use SMJobBless instead and the calls to IOHIDDeviceOpen immediately started to succeed. So to me it really looks like this is a current limitation of SMAppService.daemon(plistName:) vs SMJobBless() for this purpose. Should I file a radar or DTS incident about this? Being able to get exclusive access of any HID device (including "keyboards" like Amazon's Fire TV remotes) is absolutely critical to my app - and it would be great to know that this will continue to be possible on macOS even when SMJobBless() goes away (or defunct) some day. (and of course I really would love to use SMAppService instead - the API is so much nicer - especially when used from Swift :-) )

[quote='852123022, DTS Engineer, /thread/795686?answerId=852123022#852123022'] Does your SMJobBless code still work? That is, if you take an old build of your app and run it a modern version of macOS, can it successfully use IOHIDDeviceOpen? [/quote] Yes, it does. On the same system, the SMJobBlessed privileged helper is able to IOHIDDeviceOpen the device, whereas a new project using SMAppService.daemon(plistName:) is rejected from doing so with a kIOReturnNotPermitted error being returned. Neither the app nor the XPC service are sandboxed and Hardened Runtime is used with defaults for both (everything unchecked). The SMJobBless version is signed with Developer ID, the SMAppService version is currently just signed with the Development certificate. I'm not sure if it is relevant, but I noticed in the logs that when using SMAppService, the XPC service is resolved as anon by runningboardd: runningboardd: [com.apple.runningboard:process] com.mycompany.myservice: RunningBoard doesn't recognize submitted process - treating as a anonymous process runningboardd: [com.apple.runningboard:process] Resolved pid 18156 to [anon<com.mycompany.myservice>:18156] In contrast, going through SMJobBless, the XPC service is resolved as osservice: runningboardd: [com.apple.runningboard:process] Resolved pid 3711 to [osservice<com.mycompany.myservice>:3711]

The crash still occurs in Xcode 26 beta 2 under macOS Tahoe beta 2 here, too. A clean & build didn't resolve the issue, either. I also couldn't find any mention of this issue in the release notes for Xcode 26 beta 2, so I assume it's still pending to be fixed.

One user of my app Remote Buddy has also reported an issue where AEDeterminePermissionToAutomateTarget does never return - despite being called with askUserIfNeeded set to false: status = AEDeterminePermissionToAutomateTarget(self.targetAppEventDescriptor.aeDesc, typeWildCard, typeWildCard, false); The sample taken with Activity Monitor eventually shows the call is hanging in a semaphore: OS Version:&#9;&#9;&#9;Mac OS X 10.15.7 (19H2) … &#9;&#9;2760 Thread_6411257&#9; DispatchQueue_10: com.apple.root.default-qos&#9;(concurrent) &#9;&#9;&#9;2760 start_wqthread&#9;(in libsystem_pthread.dylib) + 15&#9;[0x7fff6daecb77] &#9;&#9;&#9;&#9;2760 _pthread_wqthread&#9;(in libsystem_pthread.dylib) + 220&#9;[0x7fff6daed9f7] &#9;&#9;&#9;&#9;&#9;2760 _dispatch_worker_thread2&#9;(in libdispatch.dylib) + 92&#9;[0x7fff6d8a2097] &#9;&#9;&#9;&#9;&#9;&#9;2760 _dispatch_root_queue_drain&#9;(in libdispatch.dylib) + 326&#9;[0x7fff6d8a1957] &#9;&#9;&#9;&#9;&#9;&#9;&#9;2760 _dispatch_queue_override_invoke&#9;(in libdispatch.dylib) + 763&#9;[0x7fff6d8954b0] &#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;2760 _dispatch_client_callout&#9;(in libdispatch.dylib) + 8&#9;[0x7fff6d893658] &#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;2760 _dispatch_call_block_and_release&#9;(in libdispatch.dylib) + 12&#9;[0x7fff6d8926c4] &#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;2760 __89-[ISPermissionAppleEvents _asyncDeterminePermissionAskingUserIfNeeded:completionHandler:]_block_invoke&#9;(in ISPermissionKit) + 96&#9;[0x1050d9e6f] &#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;2760 AEDeterminePermissionToAutomateTarget&#9;(in AE) + 1313&#9;[0x7fff34dc7f2c] &#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;2760 _dispatch_semaphore_wait_slow&#9;(in libdispatch.dylib) + 98&#9;[0x7fff6d893fbf] &#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;2760 _dispatch_sema4_wait&#9;(in libdispatch.dylib) + 16&#9;[0x7fff6d893aed] &#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;&#9;2760 semaphore_wait_trap&#9;(in libsystem_kernel.dylib) + 10&#9;[0x7fff6da2de36] And I have found more reports of the same issue: answers.microsoft.com/en-us/msoffice/forum/all/1630-hangs/ef520fd6-7df0-405c-ab3b-2dde2e7db25c (including a sample as well, ending just like the one above) stackoverflow.com/questions/59125192/authorization-by-aedeterminepermissiontoautomatetarget-waits-infinit-time#comment114813708_59125192 (see the comments, which were posted only recently) That to me suggests that issue is more widespread. I have also filed a radar/feedback on this issue: FB8919870.