Hi, and apologies for a long post! We have created an app that enables wireless communication with FIDO2 devices over Bluetooth by creating virtual HID devices and translating the packages. In order to do this, we use the HIDVirtualDevice class as described here: https://developer.apple.com/documentation/corehid/creatingvirtualdevices We learned the hard way that this sample code does not work without the “com.apple.developer.hid.virtual.device“ entitlement, but with it, it behaves as expected. Now, our application has been rejected during Review, both by the initial App Review and the appeal to the App Review Board. The problem is that I can’t really figure out what the issue is. The first rejection states the following: The app requests access to Accessibility features on macOS but does not use these features for accessibility purposes. Specifically, the app uses Accessibility features for non-accessibility feature. (Please see attached screenshot) The attached screenshot is of the screen the app shows when requesting permissions, with this code: else if bluetoothManager.requirePermissions { GradientTitle(text: "PERMISSIONS \nNEEDED") Text( """ This application requires additional permissions to run. Open the settings menu to allow access before restarting the application. """ ) and a button with this action: if let url = URL( string:"x-apple.systempreferences:com.apple.preference.security?Privacy_Accessibility" ) { NSWorkspace.shared.open(url) } The requirePermissions boolean is set from here, let properties = HIDVirtualDevice.Properties( descriptor: VirtualDevice.fidoDescriptor, vendorID: VirtualDevice.vendorId ) if HIDVirtualDevice(properties: properties) != nil { await MainActor.run { self.requirePermissions = false } break } else { await MainActor.run { self.requirePermissions = true } When HIDVirtualDevice(properties: properties) is called, a system pop-up with App would like to control this computer using accessibility features. Grant access to this application in Security and Privacy preferences located in System Preferences. shows. I responded to the rejection by trying to argue that allowing you to use your device wirelessly does increase accessibility, and that this is the only purpose of the app. Their response was: Regarding 2.4.5, Accessibility usage. To resolve this issue, it would be appropriate to remove Accessibility usage for non-accessibility purposes. Should you require more assistance with resolving this issue, Apple Developer Technical Support is available to provide direct one-on-one support for discrete code-level questions. Please be sure to include any crash logs, screenshots or steps to reproduce this issue in your request. I contacted technical support and tried to explain the issue again, and got the following response: Guideline 2.4.5 - Performance The app requests access to Accessibility features on macOS but does not use these features for accessibility purposes. Specifically, the app uses Accessibility features for non-accessibility feature. Accessibility features are intended to help users with different capabilities interact with their devices and app. Apps may not use features designed to increase accessibility for other purposes. We understand that the reason for using Accessibility feature on macOS. However, the usage is not compliant with the provided guideline. The last sentence is not complete, and it’s hard to understand what the issue is, given that they have not actually responded to my arguments. My best guess right now is point 2.4.5 (v): 2.4.5 Apps distributed via the Mac App Store have some additional requirements to keep in mind: (v) They may not request escalation to root privileges or use setuid attributes. If this is the case, I can understand the rejection, although it’s strange they didn’t just say so then. If that is correct, given that the system pop-up and accessibility requirement also trigger when running their sample code (which creates a virtual keyboard), does that mean that no one using this class and framework can submit apps to the App Store? I never intended to use an accessibility framework, and I was quite surprised the first time the pop-up appeared. RIght now I'm just confused and dissapointed with the level of feedback from Apple, and would appreciate any help, either in providing a solution or just explaining what the specific issue is.

Hi! We have created an app that communicates with devices over BLE, and it is currently out in Testflight. It works as expected for almost everyone, but for some users we get a strange behaviour. We start by scanning for devices with scanForPeripherals(withServices:options:), then connect, and finally initiate pairing by subscribing and writing to a pair of characteristics, which both require encryption. The issue is that for these users, the following code: func peripheral( _ peripheral: CBPeripheral, didDiscoverCharacteristicsFor service: CBService, error: Error? ) { guard error == nil else { LogManager.shared.log( "❌ Error discovering characteristics: \(error!)" ) return } for characteristic in service.characteristics ?? [] { if characteristic.uuid == controlPointUUID { controlPointCharacteristic = characteristic LogManager.shared.debugLog( "Control Point characteristic found." ) } else if characteristic.uuid == statusUUID { statusCharacteristic = characteristic LogManager.shared.debugLog("Notify characteristic found.") } } if statusCharacteristic != nil { LogManager.shared.debugLog("Call Set notify.") peripheral.setNotifyValue(true, for: statusCharacteristic!) } } func peripheral( _ peripheral: CBPeripheral, didUpdateNotificationStateFor characteristic: CBCharacteristic, error: Error? ) { if error != nil { LogManager.shared.log( "❌ Failed to subscribe to \(characteristic.uuid): \(error.debugDescription)" ) produces this error: > > [22:31:34.632] ❌ Failed to subscribe to F1D0FFF2-DEAA-ECEE-B42F-C9BA7ED623BB: Optional(Error Domain=CBATTErrorDomain Code=15 "Encryption is insufficient." UserInfo={NSLocalizedDescription=Encryption is insufficient.}) So in essence, we can't perform pairing and enable encryption, because we have insufficient encryption. I know that the system caches some key material after pairing. When I do "Forget device" and then pair again, I don't need to put my device in pairing mode for the pairing pin to appear, which is not the case for devices that have not been paired before. Given that I can't reproduce the problem locally, it's hard to debug using the console. What I've been trying to do is figure out how to reset Bluetooth, which should hopefully remove old keys and whatever else might be there. The top hit when searching for 'clear corebluetooth cache macos' is on stackexchange, and writes: Turn off Bluetooth Delete com.apple.Bluetooth.plist from /Library/Preferences Delete files named com.apple.Bluetooth.somehexuuidstuff.plist from ~/Library/Preferences/ByHost (note that this is the user preference folder, not the system one) Turn on Bluetooth The answer is from December 2013, so it's not surpising that things don't work out of the box, but anyways: My ByHost folder does not contain any plist files with Bluetooth in them, and deleting the one in /Library/Preferences did not do anything, and judging from the content, it does not contain anything valuable. I have tried "sudo grep -r 'Bluetooth' ." in both /Library/Preferences/ and ~/Library/Preferences/ and looked at the resulting hits, but I can't seem to find anything meaningful. As a sidenote, does anyone know what is going on with Apple's entitlement service? We applied for an entitlement in August and have yet to receive a response.