created a feedback assistant ticket for this issue: FB21939656.

So with attempt to re-query the SDP in just any form, I tried to manually query the on-device SDP server. For that, once IOBluetoothDevice got connected, I tried to open L2CAP channel, i.e. [_device openL2CAPChannelAsync: &sdpch withPSM: kBluetoothL2CAPPSMSDP delegate: self]. This, however, fails. The console output is as follows: -[IOBluetoothL2CAPChannel setupL2CAPChannelForDevice] No channel <IOBluetoothL2CAPChannel: 0x600001fa02c0> -[IOBluetoothL2CAPChannel waitforChanneOpen] PSM:1 Timed out waiting to open -[IOBluetoothDevice openL2CAPChannelSync:withPSM:withConfiguration:delegate:] PSM:1 error -536870212 -[IOBluetoothL2CAPChannel connectionComplete:status:] <IOBluetoothL2CAPChannel: 0x600001f94160 PSM:1> -536870212 channel open complete with status: e00002bc last line just reports the code that is passed to -[l2capChannelOpenComplete:status: delegate method. Either I'm making a very stupid mistake, or it is not permitted to query the SDP for third party macOS apps.

To be more specific it seems that calling performSDPQuery and performSDPQuery:uuids: has no effect other than returning kIOReturnSuccess. Analyzing communication using PacketLogger shows no SDP communication after this method is called.

Oh, it works! I entirely forgot that I did an OS-reinstall and I have to install bluetooth diagnostic profile.

I have a legacy codebase which sets up a thread and registers IOHIDDevice callbacks with its runloop, but it also does IOHIDDeviceSetReport calls from multiple other threads. From what you wrote my understanding is that it "may work", things will not crash, but in general it is a design to avoid and could cause weird behavior under some circumstances.

Long story short, I've finally managed to find a way to make lldb, TCC and command line program work nicely together when it comes to interaction with HID devices. This can be achieved by embedding a minimal Info.plist (containing the CFBundleIdentifier key into the binary).

I'd also be interested to get this clarified... If I spawn a background thread and set it up to run its own runloop, can I then use IOBluetooth from that thread (submitting all the method invocations via its runloop)? Or will IOBluetooth still refer to main thread for what it does?

A bit of improvement to the workaround that also seems to work (but is nasty): cd ~/Library/Developer/Xcode/DerivedData/myproject/SourcePackages/checkouts/mypackage chmod -R u+w . git pull origin master

Thanks for your answer, Quinn. Yes, I'm using SMLoginItemSetEnabled to register the agent. When debugging, I run the agent direcly from Xcode instead of relying upon it to be started by launch services. I have tried to follow your advice, but apparently I am still doing something wrong, because NSXPCConnection.remoteObjectProxyWithErrorHandler() calls made in app extension do fail with: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named S1J6DZ9E7U.com.myapp.agent.srv2 was invalidated: failed at lookup with error 159 - Sandbox restriction. Looking at the application bundle I think I am using the correct application group % codesign -dv --entitlements - agent.app/Contents/MacOS/agent Executable=/Users/user/Library/Developer/Xcode/DerivedData/MyApp-eylcetoqyczzehhcpvnjldtuqcay/Build/Products/Debug/agent.app/Contents/MacOS/agent Identifier=com.myapp.agent Format=app bundle with Mach-O thin (x86_64) CodeDirectory v=20500 size=114401 flags=0x10000(runtime) hashes=3564+7 location=embedded Signature size=4783 Signed Time=7 Apr 2022 at 11:53:59 Info.plist entries=24 TeamIdentifier=S1J6DZ9E7U Runtime Version=12.1.0 Sealed Resources version=2 rules=13 files=4 Internal requirements count=1 size=184 [Dict] [Key] com.apple.security.application-groups [Value] [Array] [String] S1J6DZ9E7U.group.com.myapp.agent [Key] com.apple.security.get-task-allow [Value] [Bool] true % codesign -dv --entitlements - agent.app/Contents/PlugIns/FPExt.appex/Contents/MacOS/FPExt Executable=/Users/user/Library/Developer/Xcode/DerivedData/MyApp-eylcetoqyczzehhcpvnjldtuqcay/Build/Products/Debug/agent.app/Contents/PlugIns/FPExt.appex/Contents/MacOS/FPExt Identifier=com.myapp.agent.FPExt Format=bundle with Mach-O thin (x86_64) CodeDirectory v=20500 size=5095 flags=0x10000(runtime) hashes=148+7 location=embedded Signature size=4783 Signed Time=7 Apr 2022 at 11:53:55 Info.plist entries=22 TeamIdentifier=S1J6DZ9E7U Runtime Version=12.1.0 Sealed Resources version=2 rules=13 files=0 Internal requirements count=1 size=188 [Dict] [Key] com.apple.application-identifier [Value] [String] S1J6DZ9E7U.com.myapp.agent.FPExt [Key] com.apple.security.app-sandbox [Value] [Bool] true [Key] com.apple.security.application-groups [Value] [Array] [String] S1J6DZ9E7U.group.com.myapp.agent [Key] com.apple.security.get-task-allow [Value] [Bool] true [Key] com.apple.security.network.client [Value] [Bool] true [Key] com.apple.security.network.server [Value] [Bool] true Where com.myapp.agent is budle id of my launch agent, com.myapp.agent.FPExt is a bundled file provider extension. The agent creates XPC listeners with mach service names: S1J6DZ9E7U.com.myapp.agent.srv1 and S1J6DZ9E7U.com.myapp.agent.srv2. I try to connect from the extension to S1J6DZ9E7U.com.myapp.agent.srv2, but I'm getting the error as mentioned above. I have also tried to define dedicated application groups for each of the XPC services and added them to target entitlements, but it doesn't help either. Am I doing something wrong? Or maybe you could advise how to diagnose the problem?

Turns out that PluginKit error was due to --deep codesigning flag enabled for the app target. The original error was caused by lack of $(TeamIdentifierPrefix) prefix in NSExtensionFileProviderDocumentGroup.

further analysis of console logs indicates the root cause, logged from com.apple.PlugInKit "rejecting; Ignoring mis-configured plugin at ......: plug-ins must be sandboxed" This is still very strange, because my file provider extension target has app sandbox target enabled. It looks like when Xcode is embedding the extension into main app target, it overwrites it's entitlements with entitlements of main app (thus dropping the app-sandbox entitlement present at earlier stages of the build).

Additional observation is that disabling library validation in hardened runtime settings allows my code to launch. I would rather avoid having this setting on (all dynamic libraries are included in the application bundle and there is no reason to expect that their binaries should change).