Hi everyone, I am developing a .NET MAUI Mac Catalyst app (sandboxed) that communicates with a custom vendor-specific HID USB device. Within the Catalyst app, I am using a native iOS library (built with Objective-C and IOKit) and calling into it via P/Invoke from C#. The HID communication layer relies on IOHIDManager and IOUSBInterface APIs. The device is correctly detected and opened using IOHIDManager APIs. However, IOHIDDeviceRegisterInputReportCallback never triggers — I don’t receive any input reports. To investigate, I also tried using low-level IOKit USB APIs via P/Invoke from my Catalyst app, calling into a native iOS library. When attempting to open the USB interface using IOUSBInterfaceOpen() or IOUSBInterfaceOpenSeize(), both calls fail with: kIOReturnNotPermitted (0xe00002e2). — indicating an access denied error, even though the device enumerates and opens successfully. Interestingly, when I call IOHIDDeviceSetReport(), it returns status = 0, meaning I can successfully send feature reports to the device. Only input reports (via the InputReportCallback) fail to arrive. I’ve confirmed this is not a device issue — the same hardware and protocol work perfectly under Windows using the HIDSharp library, where both input and output reports function correctly. What I’ve verified •Disabling sandboxing doesn’t change the behavior. •The device uses a vendor-specific usage page (not a standard HID like keyboard/mouse). •Enumeration, open, and SetReport all succeed — only reading input reports fails. •Tried polling queues, in queues Input_Misc element failed to add to the queues. •Tried getting report in a loop but no use.

Problem Description: Since Our USB hubs are capable of sending Vendor Defined Messages (VDMs) over a USB Type-C cable connection, they can programmatically place iOS, iPadOS, and macOS devices into DFU mode—without requiring any physical button interaction. Recently, we identified an issue when invoking DFU mode on an iPhone 15 using this method. Upon entering DFU mode, the device enumerates with USB Product ID 0x1881 (“Debug USB” – KIS interface). At that point, the deviceinterfaced daemon (launched by launchd) immediately detects the device and claims exclusive access to the USB interface. As a result, when our API Service attempts to communicate with the device through standard IOKit methods, it fails with the following error: 0xe00002c5 ((iokit/common) exclusive access and device already open) This prevents our libraries from reading the iBoot string (USB serial number string) that Apple devices normally expose in standard or recovery modes—information that includes ECID, CPID, CPRV, CPFM, BDID, and SCEP. This creates a significant barrier, as our API service becomes unable to perform subsequent device restoration operations as we missed the critical information. Request for Guidance: I’ve included the following context for your analysis and review. Using the launchctl unload command can temporarily stop it; however, I’d like to know if there’s an API-level mechanism to programmatically prevent deviceinterfaced from claiming access from within our API Service. Could you please advise on the following points? 1.  Managing deviceinterfaced Access • What is the proper way to stop or prevent deviceinterfaced from claiming exclusive access in this case, so that the API Service can read device information and starts restoring the device from that point? • Is there a recommended method or entitlement that allows third-party services to communicate with Apple devices while they are in Debug USB (KIS) mode? 2.  Guidelines and API Access • Are there any Apple-supported APIs or developer guidelines that would permit controlled access to the iBoot interface without conflicting with deviceinterfaced?

I have bought iphone 16 pro max on October 28, ( 9 months ago) and rarely dropped by battery health below 20%. I also set limit to 80% so I can preserve my Battery Health. I am not a multitasking user. I used fan to keep the phone cool during charging. But today I update to iOS26 public beta, It dropped to 99% at 88 Cycle which is quite low cycle. Many other user are getting their battery health dropped to 99% after 120, 130+ cycle with daily usage. Why mine got dropped after updating. I am quite unhappy with it, and iOS 26 is so jittery in my phone

Hi, we have developed an application that streams data from two BLE peripherals at a rate of 14.5kbps per peripheral. Until now, our devices streamed in near real time with no lag on all Apple devices with Bluetooth 5.0 or greater. Since the release of the iPhone 17 series and the iPad A16, we have reports from users of the data being streamed at significantly lower rates than expected. Any help here would be greatly appreciated as our customers are being affected by this change.

After update to MacOS Sonoma 14.7.1 (23H222) my external monitor immediately started to flicker (noticeable even on 100Hz refresh rate). During the update the external monitor was connected to the laptop. Flickering persist on personal Windows laptop too. Tried to connect/disconnect current cables, flickering persists. Tried to switch to another cable Display port to HDMI, flickering persists. Monitor now is basically unusable, the update damaged it.

I recently updated both my phones iPhone 14 Pro Max and iPhone 16 Pro Max on iOS 18.1, and after update when I open camera and go to SLO-MO the screen starts flickering, even though after recoding when I play the video. Video is playing the same with the flickering screen. is it iOS update issue or something else.

I have two Dockkit anomolies to report. Hoping a DTS person has seen these and/or can comment. First, my setup: I am controlling the accessory by making repeated calls to set the angular velocity. And the first thing I do is make a call dockManager.setSystemTrackingEnabled(false) because I'm doing my own tracking. I would note that I tried calling track() on my own, with a bunch of observation rectangles (or even just one) but it didn't work well, even though I was calling at the correct rate. Instead, I measure the angular deviation to where I wish my camera was pointed, and set the angular velocity proportional to the error. First issue: in normal operation, the green tracking light is on, on the hardware (the Instaflow Pro 360 motorized dock). Squeezing the trigger toggles the green light on/off; only when the light is on will the dock accept my calls to set the angular velocity. Fine. But sometimes squeezing the trigger won't reactivate the green light. In this case, the ONLY thing that seems to work is switching to the Instaflow Pro 360 app, and activating the camera. Immediately the green light turns on, and I'm good (and can return to my own app, with the green light still on). So what hidden API call does Instaflow have, that I don't that can make this happen? Sure, it's their own app, but I imagine they don't have access to calls I don't, so how does their app manage to get the green light back on? It doesn't always happen. Would love to know how to snap out of this. Second issue: While I usually use rectangle from running the vision system to guide my camera position, sometimes I left the user directly control the angular "yaw" velocity (rotation around the vertical axis) directly (by issuing commands over the network). Sometimes, when the user sets a non-zero velocity, when they set a zero velocity a short time later, the camera doesn't immedately respond and stop. (It's not a network issue. I can verify the API sends a call to set the angular velocity to zero, and the camera keeps rotating for a good fraction of a second.) Most times the camera stops immediately, but sometimes it doesn't. Oddly, I never see this issue when letting the user set the angular velocity in the "pitch up/down" axis. Just the yaw axis. Anybody else seen this? I feel like it wasn't a problem till I got to iOS18 but I won't swear to it. Any advice/assistance/discussion greatly appreciated.

We are reaching out to discuss an issue we have encountered with our app's activation process while running in the background. Currently, we are employing an iBeacon-based activation scheme, but we have noticed that after the app is activated, it is unable to receive UUID data from the scan-response while in the background. We are considering the possibility of embedding the UUID data into the advertisement so that the app can receive it once activated by the iBeacon. Additionally, we are preparing to use both Core Bluetooth’s “Performing Long-Term Actions in the Background” feature and the iBeacon scheme simultaneously for app activation. We would like to know if these two methods can coexist without any mutual interference. Currently, we are utilizing a method of updating the beacon advertisement after connection and disconnection to enhance the app's activation capability. However, in some scenarios where the signal is weak, the app does not detect the vehicle after being activated and will not be reactivated by the same beacon after going into sleep mode. Our current approach is to update the beacon advertisement every 10 seconds to improve this capability. We have outlined our proposed changes and would appreciate your confirmation on whether they could lead to better optimization: 1.Embedding the UUID from the scan-response into the advertisement. 2.Updating the iBeacon advertisement content every 10 seconds. 3. Simultaneously using Core Bluetooth's "Performing Long-Term Actions in the Background" feature along with the iBeacon scheme for app activation. Additionally, we would like to know if these changes could potentially cause any other issues. Thank you for your assistance, and I look forward to your insights on this matter.

My test was conducted by changing the pink dice to have a 16 bit UUID using the ASKSampleAccessory app. Afterwards, I ran AccessorySetupKit Picker in the ASKSample app, but Pink dice was not found. We confirmed that Pink dice was searched well in other apps. Does AccessorySetupKit not support 16 bit UUID? AccessorySetupKit Sample code : https://developer.apple.com/documentation/AccessorySetupKit/authorizing-a-bluetooth-accessory-to-share-a-dice-roll

I am working on a Bluetooth Low Energy (BLE) project using the nRF52840 Development Kit (DK), which has been reconfigured to simulate an nRF52805 chip. The firmware is based on Nordic Semiconductor's ble_app_hids_keyboard example, with modifications to implement a BLE HID Gamepad. I am using the S113 SoftDevice and have successfully tested the functionality with Android devices. The gamepad is recognized as a HID device, and it works as expected on Android, verified using the hardwareTester website. However, when I connect the gamepad to an iPhone via BLE, the same hardwareTester website does not respond as it does on Android, indicating that the iPhone does not recognize the device as a gamepad. The BLE connection is established successfully, but it seems iOS does not interpret the HID report descriptor or the BLE HID service correctly. I suspect there might be compatibility issues with the HID descriptor or the GATT attributes for iOS-specific BLE HID requirements. I would like to have some help.

New projects in Xcode do not include an Info.plist. Where do I put the IDs for Supported External Accessory Protocols?

I upgraded my iPhone 13 Pro Max last week, but I am unable to connect my Sony WH-1000XM5 headphones via Bluetooth. I'm not sure why everything else connects just fine except my headphones. Please send help.

Six months ago I wrote FB14122473, detailing how the built-in CDC (or FTDI) VCP serial port driver is limited to 3 Mbps or less. Thing is, there are some FTDI devices that can do 12 Mbps (maybe more), and I have devices I need to communicate with at 4 Mbps. I had to use the FTDI SDK to be able to communicate with these. I was hoping this post might help draw attention to that bug report.

Receiving "The disk you attached was not readable by this computer." for an external USB recorder that worked with MacOS 14 Aiworth voice recorder.

Apple intelligence isn’t working, it says i have it but that’s it’s also downloading. Whenever i do have it on none of the features work, what do i do

why is it that this code doesn't show the bluetooth device name but in the iOS settings it is displayed correctly. Thank you. import UIKit import CoreBluetooth import CoreLocation class BluetoothViewController: UIViewController, CBCentralManagerDelegate, CLLocationManagerDelegate { var centralManager: CBCentralManager! var locationManager: CLLocationManager! override func viewDidLoad() { super.viewDidLoad() // Initialize central manager centralManager = CBCentralManager(delegate: self, queue: nil) // Initialize location manager to request location access locationManager = CLLocationManager() locationManager.delegate = self } // CBCentralManagerDelegate Methods func centralManagerDidUpdateState(_ central: CBCentralManager) { switch central.state { case .poweredOn: // Bluetooth is powered on, request location permission if needed if CLLocationManager.locationServicesEnabled() { locationManager.requestWhenInUseAuthorization() } startScanning() case .poweredOff: print("Bluetooth is powered off.") case .resetting: print("Bluetooth is resetting.") case .unauthorized: print("Bluetooth is unauthorized.") case .unknown: print("Bluetooth state is unknown.") case .unsupported: print("Bluetooth is unsupported on this device.") @unknown default: fatalError("Unknown Bluetooth state.") } } func startScanning() { // Start scanning for devices (you can add service UUIDs to filter specific devices) centralManager.scanForPeripherals(withServices: nil, options: [CBScanOptionAllowDuplicatesKey: true]) print("Scanning for Bluetooth devices...") } func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi: NSNumber) { // This method is called when a peripheral is discovered let deviceName = peripheral.name ?? "Unknown" let deviceAddress = peripheral.identifier.uuidString print("Found device: \(deviceName), \(deviceAddress)") // Optionally, you can stop scanning after discovering a device // centralManager.stopScan() } func centralManager(_ central: CBCentralManager, didConnect peripheral: CBPeripheral) { print("Connected to peripheral: \(peripheral.name ?? "Unknown")") } // CLLocationManagerDelegate Methods (for location services) func locationManager(_ manager: CLLocationManager, didChangeAuthorization status: CLAuthorizationStatus) { if status == .authorizedWhenInUse { // Permission granted, now start scanning startScanning() } else { print("Location permission is required for Bluetooth scanning.") } } // Optionally handle when scanning stops or any errors occur func centralManager(_ central: CBCentralManager, didFailToConnect peripheral: CBPeripheral, error: Error?) { print("Failed to connect to peripheral: \(error?.localizedDescription ?? "Unknown error")") } func centralManager(_ central: CBCentralManager, didDisconnectPeripheral peripheral: CBPeripheral, error: Error?) { print("Disconnected from peripheral: \(peripheral.name ?? "Unknown")") } }

Hello! We currently require the development of an iOS system for encrypting and authorizing photos, videos, voice memos, or other files stored on our devices to a connected USB-C storage. The encrypted files can be accessed through authorization. We have already encrypted and authorized the files to be stored on the app's mobile storage, and cannot directly store them to USB-C (this requirement is based on the Apple camera RroRes, which uses external storage for direct storage). We are seeking technical support from Apple.

Current if we use the removeAccessory(_:completionHandler:) method in ASAccessorySession, it removes the accessory from the system and all apps that have previously paired also lose access. Is there a way to remove the paired accessory only from the app from where the removeAccessory() call is being made? This would be useful in cases where one or more accessories are shared across apps and we need to manage them.

We would like to be able to distinguish between iPhones and Apple Watches when scanning for devices using a Laird BLE module. We know that we can identify an Apple device from the manufacturer data returned in the scan report. 0x004C is the registered identifier for Apple. In the remaining data returned is it possible identify the device type? We note that empirically, 4C001005 seems to correlate to an Apple Watch. How reliable is this? It is useful for us, because it means we do not need to connect to this device to see if it is advertising a service that we own. Connecting over BLE is of course an expensive operation. Here is a simple snippet of a Swift App doing a similar thing, to illustrate the question: func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) { guard let manufData: Data = advertisementData[CBAdvertisementDataManufacturerDataKey] as? Data else { return } let hexEncodedManufData: String = manufData.map { String(format: "%02hhx", $0) }.joined() print("Manufacturer Data: \(hexEncodedManufData): ") // Manufacturer Data: 4c001007351ff9f9036238: Apple device // Manufacturer Data: 4c001006331ec0640f88: Apple device // Manufacturer Data: 4c0010052b18804eb1: Apple watch? // Manufacturer Data: 4c0010052b18804eb1: Apple watch? }

I have a device. After pairing, it is shown as connected in the Bluetooth list of the mobile phone. Before iOS 18, I could retrieve the device through the retrieveConnectedPeripherals method, but after iOS 18, I cannot retrieve it. What is the reason? Because when the device is connected, it no longer sends broadcast packets. How can I retrieve the device?