Hi, We are using the AX88772C as a USB->Ethernet bridge in a product we are developing. Due to the chip not following the NCM protocol, it is not supported by the default networking drivers on the iPhone. Initially, we intended on using DriverKit to develop a userspace driver for this device. However, we have been informed DriverKit is only available on iPad OS, not iOS. As such is the case, we have found two possible alternatives. First being IOkit, and the second being External Accessory Session (EASession). What are the limitations of each of these options? We need the ability to send and receive USB packets to Control and Bulk endpoints. Is this possible with either of the options defined above? Would either of these options require the device to be MFi certified? We have read that some APIs within IOkit require the apple device to be jailbroken. Is there a list of features that can be used without a jailbroken device? Documentation on these 2 options is limited, so any official documentation would be great. Thanks!

I'm developing an App that works with BLE connection based devices. The BLE connection process, which connects well to the iPhone 16 without any problems, has not worked at all since the iPhone 17. Even when using the same iOS26 version, iPhone 17 is the only one having problems. Progress is stuck after frame 124 in the entire snoop below. Please check if it is a known problem or if there is a solution. 123 2025-11-04 02:01:39.262000 0.000000 localhost () 7c:c6:b6:91:10:04 () ATT 12 Sent Exchange MTU Response, Server Rx MTU: 232 124 2025-11-04 02:01:39.265000 0.003000 localhost () 7c:c6:b6:91:10:04 () ATT 16 Sent Read By Group Type Request, GATT Primary Service Declaration, Handles: 0x0001..0xffff

I’m currently facing a disk space limitation on my Mac. I’ve already freed up some storage by following the suggestions shared in a previous post, which helped partially, but the issue is not fully resolved and space is still a bottleneck for my workflow. To move forward, I’d like to ask a very concrete question: Is it safe and supported to move Xcode to an external hard drive (SSD), use it from there, and simply connect the drive whenever I need to work with Xcode? Specifically: Are there known issues with performance, stability, or updates? Are there components that must remain on the internal disk to avoid unexpected behavior? Is this a reasonable long-term setup, or just a temporary workaround? I want to make sure I’m not setting myself up for hidden problems down the road. Thanks in advance for any clarification or best practices you can share.

I am currently trying to get my app ready for full external keyboard support, while testing I found an issue with the native DatePicker. Whenever I enter the DatePicker with an external keyboard it only jumps to the time picker and I am not able to move away from it. Arrow keys don't work, tab and control + tab only move me to the toolbar and back. This is how they look like private var datePicker: some View { DatePicker( "", selection: date, in: minDate..., displayedComponents: [.date] ) .fixedSize() .accessibilityIdentifier("\(datePickerLabel).DatePicker") } private var timePicker: some View { DatePicker( "", selection: date, in: minDate..., displayedComponents: [.hourAndMinute] ) .fixedSize() .accessibilityIdentifier("\(datePickerLabel).TimePicker") } private var datePickerLabelView: some View { Text(datePickerLabel.localizedString) .accessibilityIdentifier(datePickerLabel) } And we implement it like this in the view: HStack { datePickerLabelView Spacer() datePicker timePicker } Does anyone know how to fix this behavior? Is it our fault or is it the system? The issue comes up both in iOS 18 and 26.

Hello everyone, I’m looking for more detailed information regarding UVC (USB Video Class) over MFi within the Apple ecosystem and would appreciate some clarification. I’m interested in developing (or interfacing with) an accessory that transmits video over USB using the UVC standard, and I’d like to better understand how this works within the MFi (Made for iPhone) program. Here are my main questions: 1. Do iOS devices provide native support for UVC over USB-C or Lightning within the MFi framework? 2. Are there any specific firmware or authentication requirements when the accessory is MFi-certified? 3. Does UVC support depend solely on the hardware interface (USB-C vs Lightning), or are there additional software-level requirements? 4. Is there any official documentation outlining the recommended flow for implementing UVC-based video capture accessories on iOS? From what I understand, USB-C iPads appear to offer more direct support for standard UVC devices, but it’s not entirely clear how this integrates with the MFi ecosystem with iOS, especially for commercial product development. If anyone has gone through this process or can point me to relevant technical documentation, I would greatly appreciate the guidance. Thank you!

EASession(accessory:forProtocol:) always returns nil — MFI accessory iAP2 Platform: iOS 17+ | Hardware: Custom MFI-certified accessory (USB-C, iAP2) | Language: Swift Problem We have a custom MFI-certified accessory communicating over USB-C using ExternalAccessory. The app calls EASession(accessory:forProtocol:) after receiving EAAccessoryDidConnect but it always returns nil. We never get past session creation. What we have verified We captured a sysdiagnose on-device and analysed the accessoryd-packets log. The full iAP2 handshake completes successfully at the OS level: USB attach succeeds MFI auth certificate is present and Apple-issued Auth challenge and response complete successfully IdentificationInformation is accepted by iOS — protocol string and Team ID are correct EAAccessoryDidConnect fires as expected iOS sends StartExternalAccessoryProtocolSession — the OS-level session is established So the hardware, MFI auth, protocol string, and Team ID are all correct. Despite this, EASession(accessory:forProtocol:) returns nil in the app. We also confirmed: Protocol string in UISupportedExternalAccessoryProtocols in Info.plist matches the accessory exactly Protocol string in code matches Info.plist App entitlements are correctly configured EAAccessoryManager.shared().registerForLocalNotifications() is called before connection Current connection code @objc private func accessoryDidConnect(_ notification: Notification) { guard let accessory = notification.userInfo?[EAAccessoryKey] as? EAAccessory else { return } DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) { self.tryConnectToAccessory() } } private func tryConnectToAccessory() { DispatchQueue.main.asyncAfter(deadline: .now() + 3.0) { for accessory in EAAccessoryManager.shared().connectedAccessories { let session = EASession(accessory: accessory, forProtocol: "") // session is always nil here } } } Questions The packet log shows a ~4 second gap between EAAccessoryDidConnect firing and iOS internally completing session readiness (StartExternalAccessoryProtocolSession). Is there a reliable way to know when iOS Is it actually ready to grant an EASession, rather than using a fixed delay? Is there a delegate callback or notification that fires when the accessory protocol session is ready to be opened, rather than relying on EAAccessoryDidConnect + an arbitrary delay? Are there any known conditions on iOS 17+ under which EASession returns nil even though the iAP2 handshake completed successfully at the OS level? Is retrying EASession after a nil result a supported pattern, or does a nil result mean the session will never succeed for that connection? Any guidance appreciated.

目前这个findmy 设备是已经通过MFI认证，不过后续想的在”Find My “应用上像 AirTag 一样支持UWB测距功能。 寻找了相关资料，在这篇文章《Nearby-Interaction-Accessory-Protocol-Specification-Release-R4》中找到了UWB的相关功能，但是需要我们自己开发第三方应用。 所以需要怎么做才可以做到像airtag 一样在“Find My”应用上显示距离和方向

The FindMy device is currently MFI certified, but we plan to support UWB ranging functionality in the Find My app, similar to AirTag. After searching for relevant information, I found the relevant UWB functions in this article "Nearby-Interaction-Accessory-Protocol-Specification-Release-R4", but we need to develop third-party applications ourselves. So how can we make it display distance and direction in the "Find My" app like AirTag does?

I'm integrating AccessorySetupKit for BLE earbuds discovery and running into an issue with ASDiscoveryDescriptor configuration. Our earbuds don't have a fixed Bluetooth SIG company identifier. So I'm trying to use bluetoothNameSubstring + bluetoothServiceUUID instead. However, this combination never discovers any devices. The picker appears but stays empty. As soon as I add a bluetoothCompanyIdentifier, the device is found instantly. I reproduced this with my Bose QC35 II as well, so it's not specific to our hardware. My configuration: bluetoothServiceUUID: set to our custom UUID bluetoothNameSubstring: set to a substring matching the advertised device name NSAccessorySetupBluetoothServices + NSAccessorySetupBluetoothNames both set in Info.plist supportedOptions: .bluetoothPairingLE iOS 26.3.1, iPhone 11 The documentation doesn't mention that bluetoothCompanyIdentifier is required. Is bluetoothCompanyIdentifier actually required for BLE discovery? If so, is there a recommended approach for devices that don't have a fixed company identifier?

Environment Xcode 26.5 beta iOS 26.5 beta Using AccessorySetupKit + AccessoryTransportExtension framework Three extensions: AccessoryTransportAppExtension, AccessoryTransportSecurityExtension, AccessoryDataProviderExtension Background Everything worked correctly on iOS 26.4 beta. All three extensions shared the entitlement com.apple.developer.accessory-transport-extension, and the system launched them as expected. After upgrading to iOS 26.5 beta (both Xcode and device), the app compiles and runs, the accessory pairs and connects successfully (state = authorized, BLE connected, notification forwarding = allow), but none of the extensions are launched by the system. Investigation Captured system Console logs from the device and found these errors from deviceaccessd: error deviceaccessd ### Extension 'com.huami.NotificationForwardingDemo.AccessoryDataProviderExtension' is missing entitlement: com.apple.developer.accessory-data-provider for com.apple.accessory-data-provider error deviceaccessd ### Extension 'com.huami.NotificationForwardingDemo.AccessoryTransportSecurityExtension' is missing entitlement: com.apple.developer.accessory-transport-security for com.apple.accessory-transport-security It appears that iOS 26.5 now requires per-extension-type entitlements instead of the shared one. On iOS 26.4, all three extensions used com.apple.developer.accessory-transport-extension and it worked. On iOS 26.5, deviceaccessd now expects com.apple.developer.accessory-transport-security for the security extension and com.apple.developer.accessory-data-provider for the data provider extension. The transport app extension did not report an error, so it may still accept the old entitlement. Attempted Fix Changed the entitlement keys in the .entitlements files to match what deviceaccessd expects. Xcode fails to build with: ▎ Entitlement com.apple.developer.accessory-data-provider not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. Root Cause Checked Apple Developer Portal — only one capability is available: "Accessory Transport Extension", which maps to com.apple.developer.accessory-transport-extension. There are no separate capability options for the new entitlements. The iOS 26.5 beta system requires new per-extension-type entitlements, but the provisioning system does not yet support them. This makes it impossible to build a working AccessoryTransport app on iOS 26.5 beta. Request Please either add the new entitlement capabilities (com.apple.developer.accessory-transport-security, com.apple.developer.accessory-data-provider) to the Apple Developer Portal, or restore backward compatibility with com.apple.developer.accessory-transport-extension in deviceaccessd.

Hi, We are currently in the process of getting an custom iAP2 device communicating via USB-C. We have been using the 'EADemo' app as a test app to ensure full function before certification. Currently, the device completes the authentication and identification successfully. The device appears within the 'EADemo' app, and we are able to select it and see the available protocol. Selecting the protocol sends the EAStartSession command to the accessory and we ACK it. This is where the issues begin. Attempting to send either a string or hex packet results in nothing being sent. The app does not appear to attempt to send a packet when these are pressed. The 'EADemo' app also does not increment its receive counter when the accessory sends an EA packet, but we do receive the ACK from the device. This indicates the device is receiving the packet, but not processing it in app. Sending the EASessionStatus from the accessory with a status of okay does not change the behavior. Sending the EASessionStatus packet from the accessory with a status of closed results in the device sending an EAStopSession packet. The issue does not appear to be with the accessory or the underlying transport layer. Previous attempts to contact MFi support resulted in them referring me to developer support. Are there any known issues within the 'EADemo' app that we should know about/and or need to fix? Does Apple have any other EA example application? Are there any other publicly avalilbe EA examples that Apple would recommend us trying? Thanks, Mike