I recently noticed a UX inconsistency while using the battery charge limit feature on my MacBook with a MagSafe charger. With the optimized charging feature, users can set a custom maximum charging limit (for example, 95%) to improve battery health. However, the MagSafe LED indicator continues to show the charging state (amber) even after the device reaches this user-defined limit. Previously, the LED would turn green when charging reached 100%, clearly indicating a “fully charged” state. But now, when charging stops at a user-defined limit, there is no clear visual feedback that charging has effectively completed based on the user’s preference. This creates confusion, as the LED suggests that charging is still ongoing even though the system has stopped charging at the configured limit. A possible approach to improve this could be to treat the user-defined limit as an effective “fully charged” state during charging. For example: if is_charging: if battery_percentage < user_defined_limit: LED = AMBER else: LED = GREEN This would align the physical LED indicator with the system’s charging behavior and improve clarity for users without requiring hardware changes. Has anyone else observed this behavior, or is there any existing workaround?

I'm trying to explore accessory setup kit and migrate an existing CoreBluetooth-paired BLE device into AccessorySetupKit using ASMigrationDisplayItem. The regular ASPickerDisplayItem discovery picker works perfectly on the same device/session/Info.plist. But ASMigrationDisplayItem consistently fails. Code let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = CBUUID(string: "0xFDEE") let migrationItem = ASMigrationDisplayItem( name: "HUAWEI FreeClip 2", productImage: productImage, descriptor: descriptor ) migrationItem.peripheralIdentifier = peripheralIdentifier // peripheralIdentifier is a valid CBPeripheral.identifier UUID // CBCentralManager is suspended before this call (suspendForASK) session?.showPicker(for: [migrationItem]) { error in // Completion is either called with error 500, or NEVER called (silent no-op) } Test Results (8 rounds) # Approach Result 1 suspendForASK → immediate showPicker Silent no-op 2 suspendForASK → 0.6s delay → showPicker Silent no-op 3 .activated event → showPicker (no CBManager exists yet) Silent no-op 4 viewDidAppear → 0.5s delay → showPicker Silent no-op 5 User taps alert button (explicit gesture context) → showPicker Silent no-op 6 Clear pickerDisplaySettings before migration showPicker Error 500 (pickerAlreadyActive) 7 invalidate() → activate() → immediate showPicker (fresh session) Silent no-op 8 invalidate() → activate() → wait for .activated → showPicker Silent no-op Round 6 logs (Error 500): [ASK] Starting migration for peripheral: D0F13212-**** Picker already activated ← System message [ASK] Migration picker failed: ASErrorDomain error 500. Round 8 logs (Silent no-op, cleanest test): XPC connection invalid ← System message [ASK] Session invalidated: no error [ASK] Session activated ← New session .activated [ASK] Executing pending migration showPicker after .activated // → NO pickerDidPresent, NO migrationComplete, NO completion callback, NO error, NO UI Ruled Out Info.plist — regular ASPickerDisplayItem works with identical config Session state — .activated confirmed, session non-nil CBManager conflict — suspended before migration; round 3 ran before any CBManager existed User gesture — round 5 inside button tap handler (same context as working picker) Timing — delayed to viewDidAppear, waited for .activated event peripheralIdentifier — valid UUID, device is actively connected via CoreBluetooth Questions Is ASMigrationDisplayItem fully functional on iOS 26.x? Across 8 different invocation patterns, it either returns error 500 or silently no-ops — no UI ever appears. What causes the residual "Picker already activated" state (error 500), and how do we properly reset it? The XPC connection invalid system message appears consistently. Does this indicate the daemon is rejecting the migration request? Are there prerequisites we're missing? E.g., must the device be disconnected from CB? Must NSBluetoothAlwaysUsageDescription be removed? Is there a different descriptor requirement for migration vs discovery?

I’m debugging a custom BLE HID device on iPhone. It is a composite HID mouse + keyboard dongle. Setup: Hardware: Seeed XIAO nRF52840 Firmware: Adafruit Bluefruit Arduino / BLEHidAdafruit BLE HID report map: stock Adafruit composite HID with keyboard, consumer, and mouse reports GAP/advertising appearance: HID_MOUSE iOS adopts the device as an AssistiveTouch pointer Mouse movement and clicks work correctly Keyboard symptom: Lowercase/unshifted characters type correctly. Shifted characters lose the Shift modifier during text input: - A -> a - T -> t - DoorDash -> doordash - ! -> 1 - @ -> 2 - # -> 3 - { -> [ - } -> ] Confirmed: The iOS app sends the exact intended string to the dongle. Firmware receives the exact string. Firmware computes and sends the expected HID modifier/keycode: A sends modifier 0x02 + HID_KEY_A ! sends modifier 0x02 + HID_KEY_1 A lone isolated "A" still lands as "a", so this does not appear to be a timing or repeated-key issue. Cmd+Space works from the same HID keyboard report path and opens Spotlight. Full Keyboard Access is off. Turning AssistiveTouch off does not fix it. The iPhone never shows "Hardware Keyboard" settings for this device, even when searching Settings. Question: Is there a documented distinction on iOS between accepting BLE HID keyboard reports for global shortcuts, such as Cmd+Space, and admitting the same device as a full Hardware Keyboard for text composition? In particular: Does the absence of Hardware Keyboard settings mean iOS has not classified the device as a real external keyboard? Can a composite BLE HID device advertised as HID_MOUSE be accepted for pointer input but have Shift ignored for text input? Does iOS require a different GAP appearance, HID report-map structure, report ordering, or separate keyboard identity for Shift/modifier text composition to work? Is there a recommended way to build a BLE HID device that preserves AssistiveTouch pointer behavior while also being treated as a full external keyboard?

Body: Hello, I am experiencing a persistent and frustrating audio dropout issue after updating my Apple TV to tvOS 27.0 Beta(Build: 24J5325d).[Hardware Setup] Source: Apple TV 4K running tvOS 27.0 (24J5325d) Display: Sony BRAVIA XR-65X90L (Connected via HDMI 4) Audio System: Sony HT-S2000 Soundbar + SA-RS3S Rear Speakers + SA-SW3 Subwoofer (Connected to TV HDMI 3 eARC port) [The Problem] While watching content randomly across various apps (including YouTube, Infuse, and Apple TV app), the audio suddenly cuts out completely. The Sony TV then displays a system error message: "TV speakers activated due to audio system communication failure." This issue is intermittent, occurring once every few days. Once it happens, the eARC handshake appears completely locked up. The only way to temporarily restore the audio system connection is to perform a full system reboot of the Sony TV or toggle the Apple TV audio input source. [StepsTried/Troubleshooting] 1.Format Isolation: If I force the Apple TV audio output format to "Change Format -> Dolby Digital 5.1" instead of the default uncompressed LPCM, the connection becomes significantly more stable and the dropouts cease. 2.Cable & TV Check: All HDMI cables are Ultra High Speed (HDMI 2.1) compliant. TV settings such as "RS232C control" have been disabled, but the issue persists on the default Auto/LPCM audio output mode. [Expected Behavior] The multi-channel audio stream (LPCM/Atmos) sent from Apple TV should pass through the eARC chain smoothly without causing HDMI-CEC/eARC packet collision or freezing the display's audio daemon mid-playback. It seems like the LPCM audio stream packaging or the CEC heartbeat signals in this specific tvOS 27.0 beta build occasionally send corrupted or unexpected data packets, triggering an aggressive eARC protection/fai-safe mechanism on the Sony TV side. Is anyone else experiencing similar eARC dropouts with Sony sound systems on this beta? Any insights from the engineering team regarding HDMI/CEC driver changes in this build would be highly appreciated. Thank you!

Basic Information:tvOS Build: tvOS 18 Developer Beta (Build 24J5325d)Apple TV Model: Apple TV 4KConnected TV Model: Sony XR-65X90L (Firmware up to date)Connection Setup: Apple TV connected directly to Sony TV via High-Speed HDMI cable.Summary:After updating to tvOS build 24J5325d, the HDMI-CEC (Bravia Sync) feature broken specifically for powering off the television. When putting the Apple TV to sleep (either via the Control Center or by holding the Power button on the Siri Remote), the connected Sony XR-65X90L TV remains powered on. Steps to Reproduce: Turn on both Apple TV and Sony XR-65X90L TV.Ensure HDMI-CEC is fully enabled on both devices (Control TVs and Receivers is ON on Apple TV; BRAVIA Sync Settings are fully enabled on the Sony TV).Press and hold the Power button on the Siri Remote, or open the Control Center and select "Sleep".The Apple TV goes into sleep mode, but the Sony TV stays turned on. Expected Results: The Sony XR-65X90L TV should automatically power off or enter standby mode via HDMI-CEC when the Apple TV goes to sleep. Actual Results: The Apple TV sleeps, but the Sony TV remains completely powered on, requiring the use of the original Sony remote to manually turn it off. Attempted Troubleshooting (Issue Persists): Hard reset performed on both devices (completely disconnected from AC power and HDMI cables for 60 seconds).Toggled HDMI-CEC settings OFF and ON again on both the Apple TV and Sony TV.Rescanned HDMI devices within the BRAVIA Sync settings menu on the Sony TV.

Hi Apple Team, We recently migrated our BLE accessory from a legacy CoreBluetooth pairing flow to Accessory Setup Kit (ASK) and are very happy with the simplified system-managed pairing experience. However, we've encountered a user experience challenge during first-time pairing and would appreciate your guidance on the recommended approach. Our BLE accessory requires users to perform a few important actions before the pairing can complete successfully. For example: Turn on the product to make the accessory discoverable. Complete the authentication/confirmation code displayed on both the iPhone and the accessory. With our previous CoreBluetooth implementation, we had full control over the pairing flow and could display step-by-step instructions before and during pairing. This helped users successfully complete these device-specific actions. After migrating to Accessory Setup Kit, the pairing experience is managed entirely by the system. While this provides a much cleaner and more consistent user experience, it also means we cannot present contextual guidance or instructions while the pairing flow is in progress. As a result, we're seeing a noticeable increase in first-time pairing failures because users are not aware of these required actions at the appropriate time. We understand that these requirements are specific to our accessory rather than a limitation of ASK. Our question is: what is the recommended approach for handling accessories that require user interaction during the system-managed pairing flow? Specifically: Are there any Apple-recommended UX patterns or best practices for this scenario? Is the expectation that all necessary guidance should be presented before invoking the ASK pairing sheet? Are there any upcoming enhancements to Accessory Setup Kit that would provide developers with more flexibility to improve the first-time pairing experience? We'd appreciate any guidance or recommendations from the ASK team. Understanding the intended design pattern will help us build the best possible onboarding experience for our users. Thank you!

We use BLE devices connected to an iPhone, but after updating iOS to version 26.4 from version26.2, the following issue occurred: The device operates normally immediately after pairing. However, after disconnecting and reconnecting, the connection drops approximately 30 seconds later. The details of the error passed to func centralManager(_ central: CBCentralManager, didDisconnectPeripheral peripheral: CBPeripheral, error: Error?) at that time are as follows: Error Domain=CBErrorDomain Code=7 "The specified device has disconnected from us." What could be the possible cause of this?

I'm encountering a strange behavior with one of my home's on Home app while I'm off network. When I launch the app it indicates that the hub is not responding and all of my devices are unavailable. However, on the menu bar at the bottom if I switch to "Automation" and back to "Home" the pop-up goes away and my devices are accessible again (sometimes this take a few attempts). Siri is also able to consistently control my devices without an issue. The same behavior occurs with Home app on other devices (e.g. Mac) and with other members that have access to the household. 3rd party HomeKit app like "Controller" does not have an issue. This issue began with iOS 26 and I haven't had much luck resolving the issue. I already tried rebooting everything, including removing and re-adding an Apple TV (home hub). I have other homes shared with me in Home App with similar network/environment that are still working. The home I'm having issues has the most number of devices though (over 100+).

I am currently developing an app for MacOS that needs to control HomeKit devices like lights. However, it seems like MacOS is supported on the official documentation, but not when I try to create an app ID on developer.apple.com. On the link https://developer.apple.com/apple-home/, MacOS is clearly showed as supported for MacOS. But when I try to create an app ID, it shows that it is only compatible for iOS, VisionOS and WatchOS. Could this be clarified? Best regards, orangeidle25

Summary: EASession initialization consistently returns nil on iOS 27 when connecting to a MFi-certified USB accessory. The same code and accessory work correctly on iOS 26. Apple's official EADemo sample code also fails on iOS 27. Steps to Reproduce: Connect MFi-certified USB accessory to iOS 27 device via Lightning/USB-C Observe that EAAccessory is detected: connected=YES, connectionID=34951162 Confirm protocol string is in accessory.protocolStrings Call [[EASession alloc] initWithAccessory:accessory forProtocol:@"*******"] EASession returns nil Expected Results: EASession should be created successfully, allowing input/output stream configuration. This works correctly on iOS 26 with identical code and accessory. Actual Results: EASession returns nil. System log shows: "[#ExternalAccessory] ERROR - .../EASession.m:-[EASession dealloc] - 212 unable to close session for _accessory=0x1513d3bb0 and sessionID=65536" Note: sessionID=65536 indicates EASession was partially created but immediately deallocated. Configuration: Device: 所有机型 iOS Version: 27.0 beta Xcode Version: 26.3 (17C529) Build SDK: iOS 26 SDK Accessory PPID: cfc Accessory Firmware: L.B.1 Accessory Hardware: 1.0.1 App: Both our production app and Apple's official EADemo sample code Info.plist Configuration: UISupportedExternalAccessoryProtocols includes "*****" UIBackgroundModes includes "external-accessory" Device Settings: Settings > Privacy & Security > Security > Wired Accessories: "Automatically Allow When Unlocked" Additional Notes: EAAccessory object is properly created and accessible Accessory protocol string matches exactly All MFi certificates present (certSerial: 16 bytes, certData: 608 bytes) Issue reproduced with Apple's official EADemo sample code, confirming this is not an application-level bug Issue does NOT occur on iOS 26 with same device and accessory Regression: iOS 26: Works correctly iOS 27: Fails consistently

When using AccessorySetupKit to remove accessories, a pop-up window appears when calling removeAccessory. However, the text in the pop-up window does not change according to my iPhone's language settings and remains only in English. Has anyone encountered this issue? Does Apple have any plans to address this compatibility issue?

I'm building an access-control feature. My iOS app acts as a BLE peripheral, and a fixed door reader acts as the central. The app produces an encrypted token; the reader receives that token, validates it, and unlocks the door. The reader is a custom, non-iOS BLE device (embedded module), not an Apple device. I need this to keep working while the app is in the background, and ideally after it has been terminated. I've enabled the bluetooth-peripheral background mode (UIBackgroundModes). What I understand so far (please correct me) From the startAdvertising(_:) documentation and prior forum threads, when a CBPeripheralManager advertises while the app is in the background: CBAdvertisementDataLocalNameKey is not advertised, and the advertised service UUIDs are moved to a special "overflow" area that "can be discovered only by an iOS device that is explicitly scanning for them." That seems to imply a non-iOS central cannot discover my peripheral by service UUID once the app is backgrounded. This is exactly my concern. Questions Background discovery — Given the overflow-area behavior, is there any supported way for a non-iOS central to discover an iOS peripheral that is advertising while the app is backgrounded? Or is discovery by a non-Apple scanner fundamentally blocked in that state? Advertisement payload — My token could be delivered two ways: (a) embedded directly in the advertisement (e.g. CBAdvertisementDataManufacturerDataKey / service data), or (b) via a GATT characteristic after connection. In the background, is manufacturer data / service data included in the advertisement at all, or is it dropped like the local name? Characteristic read while backgrounded — If a connection does succeed, can the reader still read or subscribe to a GATT characteristic served by my app while the app is in the background? Any limits on value size or notifications in that state? Terminated state — With State Preservation and Restoration (CBManagerOptionRestoreIdentifierKey + peripheralManager(_:willRestoreState:)), will the system keep advertising and relaunch my app into the background when the reader connects, even after the app was terminated by the system? Does the same overflow-area limitation apply to restored advertising? Force-quit — My understanding is that if the user force-quits the app (swipe up in the App Switcher), the system will not relaunch it or preserve its Bluetooth state. Is that correct, and is there any supported exception? Recommended design — Given the goal (a non-iOS reader must reliably receive an encrypted token from a backgrounded/terminated iOS app), is the peripheral role even the recommended approach? Or should I invert the roles (reader = peripheral, app = central), which seems better suited to background operation? Thanks in advance.

I have purchased an universal, non-official Apple TV remote, with a little more buttons than on the official one (i.e. the CH-/CH+) buttons. I wanted to use the GCMicroGamepad property from the underlying GCController (from GameController framework), in order to use these buttons, but although I've linked this remote to my Apple TV device (in Settings > Remotes and Devices > Learn Remote), my app doesn't recognize it (it's not being listed in GCController.controllers()). So my question is, is there something specific I can do so I can use this remote as a GCController? Or maybe is there something specific to hardware that I have to know for this to work? Thank you.

Hello, I am developing a cross-platform mobile app that communicates with an external accessory over a serial (UART) link. HARDWARE : The accessory is an optical reading probe that connects to the phone via USB. Inside the cable there is a standard FTDI USB-to-serial chip (similar to common FTDI/CP210x USB-serial adapters). WHAT WORKS On Android, our app: Detects the USB device Opens the serial port Reads and writes raw bytes successfully This wired FTDI path is fully implemented and working. WHAT DOES NOT WORK On iPhone, using the same wired FTDI USB accessory: We connect via Lightning or USB-C adapter The app never sees the FTDI device We cannot find a public iOS API to open a generic USB-serial port MY QUESTION : Is there any supported way for a third-party iOS app to communicate with a generic FTDI USB-serial device over a wired USB connection? Specifically, am I missing: A public Apple framework for USB serial? An Info.plist key or entitlement? A system driver on iOS similar to macOS AppleUSBFTDI (TN2315)? Or is wired USB-serial on iPhone only possible with MFi-certified accessories (External Accessory framework) or another transport such as Bluetooth LE? WHAT I HAVE ALREADY CHECKED External Accessory: seems to require MFi hardware and a registered protocol string. Our FTDI probe is not MFi. TN2315 (AppleUSBFTDI): appears to be macOS only, not iOS. Physical USB connection: cable fits, but no serial API is exposed to the app. ENVIRONMENT Platform: iOS (iPhone) Language: C# / .NET-iOS Need: transparent byte-level serial read/write SUMMARY: Android USB-serial works with our FTDI wired accessory. iOS does not. Am I missing something on iOS, or is generic FTDI USB-serial simply not supported for third-party iPhone apps? Thank you for any guidance.

Environment: iPhone 17 / iPhone 17 Pro (Apple N1 chip) iOS 26.x Xcode 26 Framework: Flutter app with native iOS BLE library (CoreBluetooth) We have a production IoT app that communicates with BLE nodes (Nordic, PIC, EnOcean peripherals) using an advertising/scanning-based protocol — not GATT connections. The app broadcasts commands via CBPeripheralManager (advertising service UUIDs) and receives responses by scanning with CBCentralManager (reading manufacturer data and service UUIDs from advertisement packets). This workflow has been reliable across all iPhone models from iPhone 8 through iPhone 16 Pro Max. On iPhone 17 devices, we are experiencing multiple failures in this workflow. Architecture: Sending commands: We use CBPeripheralManager.startAdvertising() with CBAdvertisementDataServiceUUIDsKey to broadcast a UUID-encoded command to nearby nodes. Receiving responses: We use CBCentralManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true]) and filter responses in centralManager(_:didDiscover:advertisementData:rssi:) by matching CBAdvertisementDataServiceUUIDsKey or CBAdvertisementDataManufacturerDataKey against expected UUID masks. Communication pattern: Advertise a command → stop advertiser → start scanner → wait for matching response → process result. Typical timeout is 1.5 seconds per exchange. Issues observed on iPhone 17: peripheralManagerDidStartAdvertising behaviour change After calling CBPeripheralManager.startAdvertising(:), the delegate callback peripheralManagerDidStartAdvertising(:error:) either fires with errors that did not occur on previous hardware, or advertising does not appear to reach the peripheral nodes at all. The same advertising payload works immediately when tested on iPhone 15/16. Is the N1 chip's Bluetooth 6 stack handling CBAdvertisementDataServiceUUIDsKey advertising differently? Are there new constraints on advertising payload size or format? Scanner returning fewer/no results with withServices: nil Our scanner uses scanForPeripherals(withServices: nil) because we need to read manufacturer data from advertisement packets and filter using a custom UUID mask. On iPhone 17, we observe significantly fewer didDiscover callbacks compared to iPhone 15/16 in the same physical environment, with the same nodes advertising. We understand that passing service UUIDs in withServices: is recommended, but our protocol requires reading raw manufacturer data bytes that aren't associated with a single service UUID — we use mask-based matching (e.g., filter mask 11110000-0000-0000-0000-000000000000 against scan results). Has the N1 chip changed the rate or filtering behaviour of unfiltered BLE scans? Is there a new throttling mechanism? Background scanning stops immediately When the app moves to background, scanning appears to stop entirely on iPhone 17 — even with bluetooth-central in UIBackgroundModes. On iPhone 16, background scanning continued (at reduced intervals) and delivered results for peripherals advertising filtered service UUIDs. Aggressive session termination on app backgrounding Our advertise-then-scan sequences (typically 1.5s round-trip) are being interrupted when the user briefly switches apps. The CBPeripheralManager stops advertising and the CBCentralManager stops scanning, causing timeout errors. This was not observed on previous iPhone models with the same iOS background mode configuration. Questions for Apple: Are there documented changes to CoreBluetooth behaviour on the N1 Bluetooth 6 chip that affect advertising-based (non-GATT) communication patterns? Has the scan response rate for scanForPeripherals(withServices: nil) been intentionally reduced on iPhone 17? Is CBCentralManagerOptionRestoreIdentifierKey now required for reliable background scanning on iPhone 17, or is this a known regression? Are there new advertising payload constraints (size, format, interval) that we should be aware of for the N1 chip? What we've tried: Added NSBluetoothAlwaysUsageDescription and NSBluetoothWhileInUseUsageDescription to Info.plist Confirmed Bluetooth permissions are granted Tested with identical BLE nodes that work on iPhone 15/16 Verified CBManagerState.poweredOn before all operations Any guidance or known workarounds would be greatly appreciated. Happy to provide sysdiagnose logs or a minimal reproducible sample project.

I'm encountering a bug developing a (Thunderbolt) PCIDriverKit dext. The system runs well for a while, and then the hardware instance is shut down by the OS (Sonoma 14.7.6) for some unknown reason, but the dext is not, so hardware reads return 0xFFFFFFFF (device disconnected). There is no crash report, or diagnostic report. I don't see anything related in a sysdiagnose capture. The only hint I can find is the kernel logs indicate: 2026-07-01 16:18:15.929 Df kernel[0:139] (AppleT8122PCIeC) apciec[pcic1-bridge]::handleCompletionTimeoutInterrupt Completion timeout detected at address 0xe00510020 2026-07-01 16:18:15.929 Df kernel[0:139] (AppleT8122PCIeC) apciec[pcic1-bridge]::handleCompleterAbortInterrupt Completer Abort received (pri_status = 0x00100407, sec_status = 0x200000f0): 2026-07-01 16:18:15.929 Df kernel[0:139] (AppleT8122PCIeC) apciec[pcic1-bridge]::handleCompleterAbortInterrupt * Received Master Abort on a link side of the Root Complex That address (0xe00510020) looks like it's our PCI device (at a BAR0, offset 0x0020) read. What does this error explicitly mean? Did the device take too long to respond to the read request? After the event, every device on that Thunderbolt bus is disconnected, and a reboot seems to be required. Hardware is a 14" 2023 MacBook Pro M3.

Hi everyone, We're working on a custom USB-C accessory based on an MCU (ARM Cortex-R8, running RT-Thread RTOS) with a Synopsys DWC3 USB Device controller. Our goal is to stream real-time sensor data (~10 Mbps) from the accessory to an iPhone via USB-C. We're planning to configure our MCU as a USB NCM device (following USB-IF NCM v1.0 spec), so the iPhone sees it as a standard Ethernet adapter. We would then run a lightweight TCP/IP stack (lwIP) on the MCU side and communicate with our iOS app via standard BSD Sockets / Network.framework over the virtual network — no gateway, just direct IP-to-IP communication within the local network that the NCM device presents. Questions: Feasibility confirmation: Based on our description, do you see any issues with this approach on iPhones including iPhone 16 and newer models? Our USB controller supports High-Speed (480 Mbps), so NCM throughput should not be a bottleneck. No-gateway concern: We don't plan to implement a DHCP server or gateway on the MCU. We'd use static IP configuration (or Link-Local addressing) for direct socket communication. Is there anything in iOS's network stack that would prevent this — for example, requiring a DHCP-assigned address or a default gateway before allowing socket traffic on the USB Ethernet interface? MFi and long-term viability: We understand this approach doesn't require MFi certification, since NCM is a standard USB-IF class and iOS has built-in Ethernet support. However, we want to make sure this doesn't go against the spirit of the MFi program or Apple's accessory policies. Is there any risk that Apple might restrict or block non-MFi NCM accessories in a future iOS update? We'd rather invest our effort in the right approach from the start. App Store review: Would an iOS app that communicates with our accessory exclusively via standard socket APIs (Network.framework / BSD Sockets) over the USB Ethernet interface face any App Store review issues — assuming it doesn't use any private APIs and doesn't declare MFi support? Any guidance would be greatly appreciated. We want to make sure we're building on a solid foundation.

Hello, My name is Jisoo Kim, and I am a product designer currently developing a tray and case accessory for the Apple Magic Keyboard and Magic Trackpad. I have reviewed the Apple Accessory Design Guidelines, however I was unable to find specific guidance covering accessories of this type. As a designer and an engineer who values complementing Apple's devices without interfering with their functionality, I want to ensure our development aligns with Apple's standards. Given the absence of specific guidelines for this product category, I have two questions: Would it be appropriate to reference guidelines from other similar Apple accessory categories as a basis for our design decisions? Are there any additional considerations or requirements we should be aware of when developing this type of accessory? Any guidance you could provide would be greatly appreciated.

Hi everyone, I am seeking clarification regarding the communication capabilities between an ESP32 microcontroller and Apple's latest devices, specifically the iPhone 16 Pro Max and iPad Pro, both equipped with USB-C ports. Background: MFi Certification: Historically, establishing communication between external devices and iOS devices required MFi (Made for iPhone/iPad) certification. But I remember this being necessary in the Lightning Cable to USB era. With the introduction of USB-C ports in recent iPhone and iPad models, there is an indication that MFi certification may no longer be necessary for certain peripherals. Perhaps I'm not confident on the terminology here: https://mfi.apple.com/en/who-should-join Project Requirements: I am working on a sensor research project that necessitates the collection of low-latency time-series data from an ESP32 microcontroller, which features a USB-C port. The data needs to be transmitted to an iPhone 16 Pro Max or iPad Pro. Bluetooth communication has proven insufficient due to its limited data transfer rates (~1.2 Mbps with L2CAP). While NEHotspot could be an alternative, it restricts the iPad's internet connectivity. Therefore, establishing a direct USB-C connection between the ESP32 and the iOS device appears to be the most viable solution. Questions: MFi Certification Necessity: Is MFi certification still required for an ESP32 microcontroller to communicate with iPhone 16 Pro Max or iPad Pro via USB-C? USB-C Communication Support: Do the iPhone 16 Pro Max and iPad Pro natively support serial communication over USB-C with microcontrollers like the ESP32? If not, are there recommended protocols or interfaces to facilitate this communication? App Development Considerations: Would developing a custom iOS application be necessary to handle data transmission from the ESP32 over USB-C? If so, are there specific APIs or frameworks provided by Apple to support this functionality? Data Transfer Rates: Considering the need for high-speed data transfer, are there any limitations or considerations regarding the data transfer rates achievable through a USB-C connection between the ESP32 and iOS devices? Thank you!

We are conducting iBeacon compliance testing for our device and would like to clarify two test items from the iBeacon test specification: Regarding Tx power stability verification over time and across different battery capacities: Could you please specify the required test duration and the exact test procedure? Specifically, how long should the Tx power be monitored to verify stability within the 2dB standard deviation requirement, and what battery capacity levels (e.g., 100%, 50%, 20%, low battery threshold) should be tested? Regarding device interoperability with iOS CoreLocation APIs for beacon-based region monitoring and ranging: Could you please provide guidance on the test methodology? Specifically, what test cases, expected behaviors, and pass/fail criteria should we follow to verify correct interoperability with region monitoring (didEnter/didExit) and ranging (didRangeBeacons) APIs? Any official test guidelines or reference documents would be greatly appreciated.