Filing this for engineering visibility and to ask whether the observed behavior matches expected M5 Pro DCP architecture. FB22701284 contains full sysdiagnose and supporting data. Hardware Configuration MacBook Pro 16-inch (Mac17,8) M5 Pro chip, 18-core CPU 64GB unified memory (highest M5 Pro memory tier) 1TB SSD macOS Tahoe 26.4.1 (build 25E253) AppleDCP-1041.100.97~429-t605xdcp.RELEASE Display Configuration Two identical LG UltraGear 27GM950B monitors: 27" Mini LED panels, native 5120x2880 DisplayPort 2.1 UHBR20 (80 Gbps capable) 165Hz native refresh, HDR-capable Connection topology (all third-party display software removed for clean test): Mac TB5 port 1 → Silkland DP80 USB-C cable (VESA-certified) → Monitor #1 USB-C input Mac TB5 port 2 → Silkland DP80 USB-C cable (VESA-certified) → Monitor #2 USB-C input DisplayLink Manager fully uninstalled No dock, no MST hub, no signal converters Apple Specification Context Per the MacBook Pro user guide, M5 Pro supports dual displays at 5K@120Hz (support.apple.com/guide/macbook-pro/apd8cdd74f57/mac), with the documented instruction to "connect the display with the highest resolution first." Observed Behavior Solo connection (either monitor) Either monitor in isolation: 5120x2880 @ 144Hz, Maximum Source Bandwidth 27,400 Mbps, 10-bit, HDR enabled. Dual connection (BetterDisplay 4.3.3 diagnostic) Monitor on dispext0@B0000000: 5120x2880 @ 144Hz, Maximum Source Bandwidth: 27,400 Mbps, HDR enabled Monitor on dispext1@90000000: Degraded from native 5K, Maximum Source Bandwidth: 13,700 Mbps, HDR disabled The 27,400/13,700 split is deterministic and follows connection order. Hardware substitution (cables, ports, monitor positions) confirmed the allocation follows position in connection order, not specific hardware. Each monitor achieves full 27,400 Mbps when solo. Per-pipe budget structure exposed in BetterDisplay 4.3.3 Recent BetterDisplay versions expose allocation limits in display reports: Allocation limits - horizontal: 3360, 3840 pixels HiDPI (6720, 7680 pixels LoDPI) Allocation limits - vertical: 2304 pixels HiDPI (4608 pixels LoDPI) This matches the per-sub-pipe budget structure documented in third-party M5 Max DCP firmware analysis, where M5 Max shows MaxSrcRectWidthForPipe = (6720, 7680, 7680, 7680). M5 Pro appears to expose only two values (6720, 7680). WindowServer assertion failure WindowServer crash on 2026-05-16 with assertion failure in the function calculating per-pipe maximum source rectangle widths: Thread 16 Crashed: com.apple.coreanimation.render-server CA::WindowServer::AppleDisplay::max_src_rect_width_by_pipes(unsigned char) const + 92 CA::WindowServer::AppleDisplay::max_src_rect_pixels() const + 60 CA::WindowServer::Server::get_display_info() + 1812 Exception: EXC_CRASH (SIGABRT), Abort trap 6. This is the same function third-party DCP firmware analysis identifies as governing the per-sub-pipe budget calculation. Reference to Existing Thread Apple CoreOS DTS Engineer Kevin Elliott in thread 814201 (https://developer.apple.com/forums/thread/814201) described M5 MacBook Pro display architecture: "Driving the display at 240Hz require both of the two display 'pipes' and the system ends up allocating both pipes to the first monitor it discovers. That prevents it from lighting up the second monitor, as there isn't currently any way for software to shift allocations of display pipes between machines." That thread addressed a single-display 4K@240Hz scenario where the second display failed to initialize. The underlying allocation mechanism (first-come-first-served pipe assignment, no dynamic reallocation) appears consistent with the dual-display configuration I'm observing, with the manifestation differing (both displays initialize but the second is bandwidth-constrained rather than absent). Specific Technical Questions Is the 27,400/13,700 Mbps asymmetric allocation observed on dual 5K configurations the expected manifestation of the two-pipe architecture described in thread 814201, or a distinct allocation policy specific to dual-display scenarios? The advertised dual 5K@120Hz capability requires approximately 28 Gbps per stream. The observed allocation appears insufficient to drive both displays at this specification simultaneously. Is there a configuration approach that allows both displays to receive adequate bandwidth allocation? Multiple sources document that M5 Max has more display engine output channels than M5 Pro. Is the architectural difference between M5 Pro and M5 Max sub-pipe count (per the BetterDisplay allocation limits and third-party firmware analysis) the underlying explanation for the differential dual-display capability? The WindowServer assertion failure in max_src_rect_width_by_pipes() — is this a known edge case for dual high-bandwidth display configurations on M5 Pro, or should this be filed as a separate issue from the bandwidth allocation behavior? Supporting Data Available BetterDisplay 4.3.3 diagnostic reports for both monitors WindowServer crash report (2026-05-16) ioreg output showing DCP unit assignments sysdiagnose attached to FB22701284 Happy to provide additional FB tickets with focused diagnostic captures if specific data would help engineering investigation.

My MacBook Pro M5 running MacOS Tahoe 26.3 beta fails to detect two identical ASUS ROG Swift OLED PG32UCDM monitors simultaneously. Only one display is recognized at a time. One potential root cause might be that both monitors report identical binary EDID serial numbers (0x01010101), and the MacBook Pro M5 appears to use this value exclusively for display identity rather than combining it with other more detailed information (e.g., port, or alphanumeric serial number). I've verified that the monitor EDID binary serial numbers are in fact identical -- however the alphanumerical serial numbers are not identical. NOTE: This behavior is specific to the MacBook Pro M5 — when connecting both monitors via usb-c to a Mac Mini M4 Pro running the same MacOS Tahoe 26.3 beta, the monitors work fine. The OS detects both and assigns different names to them (PG32UCDM (1) and PG32UCDM (2)). NOTE: I could be wrong about this root cause, I don't have a way to disprove it, though the fact the monitors work fine on a Mac Mini is suspicious. What I have tried: Connecting the two monitors using different monitor ports (one on DisplayPort, another on HDMI, etc.), and different MacBook ports (one on HDMI, another on USB-C, etc.) Bumping down the resolution on the monitors to "1920x1080 (low resolution)" and 30Hz to rule out bandwidth issues. Connecting one, or both, monitors to CalDigit TS5 Plus dock. Neither alternate configuration yields the device recognizing both screens. Using BetterDisplay to import a manually-edited EDID for the screen, with a different binary EDID value, manufacturer name, etc. I've also verified that if I plug in my Apple Studio Display as one of the monitors, then the MacBook recognizes both one of the PG32UCDM monitors and the Studio Display at the same time. The issue seems to occur only when both monitors plugged into it are the same PG32UCDM model. When I have both monitors plugged into my MacBook, each time I disconnect the cable to whichever monitor is currently recognized, it immediately recognizes the other monitor. Plugging the cable for the disconnected monitor back in has no effect. I'm at a loss. Has anyone run into this issue and found a successful workaround that is not one of the approaches I've described above?

Hi Apple Developer Support, I have performed additional experiments to investigate whether AccessoryControlDevice.current(for:) and update(_:) can be used from a custom ExtensionFoundation extension. The results have helped narrow down the issue. 1. Host app registration succeeds The host app successfully obtains the accessory from its AccessorySetupKit session and registers the placement capability: try await AccessoryControlDevice.register( accessory, capabilities: [.placement] )Log: [ASK] AAK 步骤0 ASK配件 id=22E9E2E0-46B4-9435-C0C2-4F16FB6A0568 name=Buds Pro 2 inSession=true sessionCount=1 placement=inEar state=authorized source=session.accessories sessionActivated=true caps=placement [ASK] AAK 步骤1(主App) register 成功 placement=inEar id=22E9E2E0-46B4-9435-C0C2-4F16FB6A0568The registration call completes successfully. 2. Custom ExtensionFoundation extension launches successfully I created a custom extension point using: AppExtensionPoint.Definition AppExtensionPoint.Bind AppExtensionPoint.Monitor AppExtensionProcess The host app successfully discovers the extension and launches it. Logs: [ASK][PLC] 扩展点构造成功 id=com.nothing.smartcenter.placement [ASK][PLC] Monitor 结果 identities=1 stateIdentities=1 unapproved=0 disabled=0 [ASK][PLC] 发现扩展 bundle=com.nothing.smartcenter.placement point=com.nothing.smartcenter.placement [ASK][PLC] AppExtensionProcess 创建成功 [ASK][PLC] XPCSession 创建成功 [ASK][PLC] XPCSession activate 成功 [ASK][PLC] sendSync 成功 —— 扩展已响应，进程确实起来了Therefore, the custom extension is installed, discovered, launched, and able to communicate with the host app through XPC. 3. AccessoryControlDevice.current(for:) still fails inside the extension Inside the running extension, I obtain the accessory from its AccessorySetupKit session. The session contains one accessory. However, calling: let device = try await AccessoryControlDevice.current( for: accessory )consistently fails with: AccessoryControlDevice.Error.invalidated Request invalidatedLogs: [ASK][PLC] 实验3-current 请求已送达 op=probe worn=false [ASK][PLC] e3 扩展回传： ask-session 复用 count=1 [ASK][PLC] e3 扩展回传： current FAIL AccessoryControlDevice.Error.invalidated desc=Request invalidatedThe same result occurs when attempting the placement update experiment: [ASK][PLC] 实验4-offHead 请求已送达 [ASK][PLC] e4off 扩展回传： ask-session 复用 count=1 [ASK][PLC] e4off 扩展回传： current FAIL AccessoryControlDevice.Error.invalidated desc=Request invalidatedBecause current(for:) fails, I have not yet been able to verify whether update(_:) itself works. 4. Questions for Apple I would appreciate clarification on the following points: Does AudioAccessoryKit support custom ExtensionFoundation extensions? Specifically, are extensions created using AppExtensionPoint.Definition and AppExtensionPoint.Bind, and launched through AppExtensionPoint.Monitor and AppExtensionProcess, considered valid app extensions for AudioAccessoryKit? Does AccessoryControlDevice.current(for:) require a specific system-defined extension point or extension type, rather than a custom extension point? Does AudioAccessoryKit require any additional entitlement, capability, extension configuration, or authorization for current(for:) to succeed? Is the ASAccessory instance required by current(for:) expected to be obtained from the same ASK session used by the host app during register(), or can the extension obtain the accessory from its own ASK session? What does AccessoryControlDevice.Error.invalidated / Request invalidated specifically indicate in this situation? Is there a way to obtain more diagnostic information about why the request was invalidated? Is there an official sample project demonstrating the complete integration of AccessorySetupKit, AudioAccessoryKit placement updates, and the required app extension? Environment iOS: 26.4 Accessory: Nothing Ear / Buds Pro 2 (internal model B172) Frameworks: AccessorySetupKit, AudioAccessoryKit, ExtensionFoundation, CoreBluetooth Host app bundle ID: com.nothing.smartcenter Custom extension point: com.nothing.smartcenter.placement At this point, BLE communication, AccessorySetupKit pairing, host-side AudioAccessoryKit registration, extension discovery, extension process launch, and XPC communication are all working. The remaining blocker is that AccessoryControlDevice.current(for:) returns Request invalidated even when called inside the successfully running custom extension. Could you please clarify whether this custom ExtensionFoundation architecture is supported by AudioAccessoryKit, or whether a specific Apple-defined extension type is required? Thank you for your help.

Hi everyone, I'm developing a third-party Bluetooth audio accessory and investigating AudioAccessoryKit placement updates on iOS 26.4. My goal is to update the accessory's wearing state (for example, .inEar / .offHead) based on BLE notifications from the accessory. Implementation flow Pair the Bluetooth accessory using AccessorySetupKit. Obtain the paired ASAccessory. Register the accessory in the host app: try await AccessoryControlDevice.register( accessory, capabilities: [.audioSwitching, .placement] )Attempt to retrieve the registered device: let device = try await AccessoryControlDevice.current(for: accessory)However, current(for:) consistently fails with: AccessoryControlDevice.Error.invalidated Request invalidatedBLE communication status The BLE communication itself appears to be successful. The following logs show that the command was sent and the accessory returned a response: [ASK] cmd didWrite ok 68745353-1810-4B13-83A2-C1B21B652C9B notifying=false [ASK] cmd toSend mac=2a:e6:e7:eb:be:2c model=B172 bytes=5560014FC000000F status=connected shaking=false [ASK] cmd write direct mac=2a:e6:e7:eb:be:2c bytes=5560014FC000000F chars=10 peripheral=2 delegate=Optional<CBPeripheralDelegate> connected=connected [ASK] cmd reply ok uuid=CA235943-1810-45E6-8326-FC8CA3BC45CE bytes=5560014F4001000F [ASK][PLC] Experiment 4 - inEar request delivered, op=update worn=true [ASK][PLC] Experiment 4 - inEar current baseline: current FAIL AccessoryControlDevice.Error.invalidated desc=Request invalidatedThe BLE command is successfully delivered to the accessory, and the accessory responds. However, the AudioAccessoryKit API still returns invalidated. Questions Does AccessoryControlDevice.current(for:) require a specific app extension context, entitlement, or authorization? Is it expected to call current(for:) from the host app, or must it be called from an app extension? Does registering .placement and .audioSwitching in the host app guarantee that the accessory can subsequently be retrieved using current(for:)? Are there any additional requirements for the accessory, firmware, or system-side registration before current(for:) can succeed? Is there a known issue with AccessoryControlDevice.current(for:) returning Error.invalidated on iOS 26.4? I understand that AccessoryControlDevice.update(_:) is documented as an API that must only be called from an app extension. I'm trying to determine whether the failure of current(for:) in the host app is expected behavior or indicates a registration/configuration problem. Any sample code, implementation guidance, or clarification from Apple engineers would be greatly appreciated. Thanks!

Title: AccessorySetupKit picker only reports 3 accessories when using filterDiscoveryResults Tags: AccessorySetupKit, Core Bluetooth Hi all, We recently migrated our BLE accessory pairing from our own CoreBluetooth scan flow to AccessorySetupKit. Since this is the new framework Apple recommends for accessory pairing (and with the new Bluetooth privacy model), we wanted to move fully to it. The migration went well overall, but we hit a limit in production that we couldnt find documented anywhere and it's now affecting real users. What we are doing We use .filterDiscoveryResults so we can set our own name and image for each accessory in the picker. For every .accessoryDiscovered event we create an ASDiscoveredDisplayItem and pass the full list to updatePicker(showing:completionHandler:). let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothCompanyIdentifier = ASBluetoothCompanyIdentifier(rawValue: [ID]) descriptor.supportedOptions = .bluetoothPairingLE let item = ASPickerDisplayItem(name: "[Name]", productImage: image, descriptor: descriptor) let settings = ASPickerDisplaySettings() settings.options = .filterDiscoveryResults settings.discoveryTimeout = .long session.pickerDisplaySettings = settings session.showPicker(for: [item]) { _ in } // In the event handler, for every .accessoryDiscovered event: session.updatePicker(showing: allDiscoveredItems) { _ in }The problem We only ever get 3 .accessoryDiscovered events in one picker session, doesnt matter how many of our accessories are advertising nearby. Since the picker shows only what we pass to updatePicker, the sheet never shows more then 3. Our own code has no limit, every discovered item goes to updatePicker. If we remove .filterDiscoveryResults and keep everything else same, the picker shows more than 3 accessories in the same room. So it looks like the limit only applies when filtering is on. How it affects users When there are lot of accessories around (offices, events, households with more than one), the one the user actually want to pair is often not in those 3. Users don't know there is a limit, so they keep dismissing the picker and opening it again hoping their accessory shows up this time. Understandably this is very frustrating for them, and with our old scan flow this wasn't a issue because we could list every accessory nearby. To reproduce Turn on more than 3 accessories matching the descriptor within few metres of the iPhone, present the picker with the above configuration and log every .accessoryDiscovered event. Only 3 arrive, any accessory turned on after the first 3 never shows up. Questions Is this limit of 3 intended? If yes, is there a way to raise it or reset it during the session (for example after calling updatePicker)? How the picker decides which accessories gets reported? Is there a recommended approach for crowded environments? If it's intended, can it be added to the documentation? Environment iOS Version 27.1 (27A9269), iPhone 16 pro(MYNR3HN/A), Version 27.1 (27A9269) We have filed this as FB25362032. Thanks!

Hi! We build a Matter bridge that exposes air conditioners as compound devices, following Device Library §2.5.6 "Separate Endpoints": Aggregator → Bridged Node (no application device type) → Thermostat (0x0301) + Fan (0x002B) In the Home app some of these accessories appear as a Thermostat tile and others as a Fan tile, even when the devices are identical. A matter.js test bridge with 5 identical devices gave 1 Thermostat / 4 Fan tiles on Matter 1.5.1 and the same on 1.6.0. Removing and re-adding our ESP32 bridge, with no firmware change, swapped which device was shown as a Fan. Putting the Thermostat device type on the Bridged Node endpoint itself, with the Fan as its child, gave 3 Thermostat / 2 Fan, so that is not stable either (and Device Library 1.5 §2.5.6 does not allow it). The home hub log (homed, hmmtr.protocolmap) shows "Multiple primary service candidates found" for each of these devices; the chosen service is redacted. Questions: How does Home choose the primary service for a bridged compound device? Is there a supported way for the accessory to indicate which endpoint is primary (order in PartsList, TagList, something else)? Is a single endpoint with Thermostat plus an extra Fan Control server cluster the recommended layout for Apple Home instead? Filed as FB25263651. Environment: iPhone with iOS 27.0.1, Apple TV home hub with tvOS 27.0.

Hi, i am using mopai kt393 which is listed on apple mfi devices list in web. My phone is 14 pro(ios 27) and cannot be charged via mopai kt393. I tried to use another phones : 14 pro(ios 18), 13 basic(ios 26), they were charged normally. Is this a bug of ios27? or new rules on ios 27? or mopai kt393 is actually not a mfi device? Anyone has this issue too?

We need one iOS app supporting iOS 17 and later to set up a BLE HID accessory entirely from within the app. The accessory also advertises a custom GATT service. Our iOS 18.4+ flow uses AccessorySetupKit with bluetoothHID and should remain unchanged. We need a supported public setup path for iOS 18.0–18.3, including new installations without an existing Bluetooth grant or working HID bond. Requiring pairing in Settings or a firmware change would not meet this requirement. The specific question is: what public API/configuration can establish system HID input on those older systems while the same installed app retains its AccessorySetupKit Bluetooth declarations? What we have verified on an iPhone 15 Pro Max running iOS 18.3.1 (22D72): With AccessorySetupKit Bluetooth support declared in Info.plist and no authorized accessory, our ordinary CBCentralManager stayed poweredOff. In a controlled diagnostic build with the same diagnostic app identity and code but the two ASK support declarations removed, it became poweredOn, discovered the accessory, connected, and reached custom GATT communication. This test did NOT establish first-time HID input success for the non-ASK variant. With ASK enabled, we describe the accessory using its custom advertised service, set descriptor.supportedOptions to bluetoothPairingLE, and use a display item with confirmAuthorization. During app authorization we perform the accessory security setup and then finishAuthorization. Device logs show successful pairing, encryption, saved keys, and an authorized/paired accessory. Custom GATT communication works. Actual HID input still does not work: the system receives an HID-service value but discards it because the parent characteristic has not been discovered and there is no subscribing session. Pairing the same hardware through Settings previously produced working mouse/gesture input. We did not retain a simultaneous system trace of that successful path. This confirms the hardware/system combination can provide HID input, but does not establish an app-initiated solution. We understand that Apple's ASAccessorySession documentation introduces ASK BLE HID setup in iOS 18.4 and requires bluetoothHID plus a custom advertising service. We are not treating successful bonding or ordinary GATT communication as proof of system HID readiness. Could Apple clarify which supported approach applies? Can one installed app select ordinary global Bluetooth authorization on iOS 18.0–18.3 while retaining ASK Bluetooth declarations and ASK setup on iOS 18.4+? We have not found a documented per-OS Info.plist selector or runtime opt-out, and an availability check around ASAccessorySession alone leaves the installed declarations intact. If that authorization split is not supported, is there a public app-initiated way to establish system HID discovery/subscription after ASK authorization and bonding succeed on iOS 18.0–18.3? Does using service 1812 as the ASK discovery match have any documented HID setup effect on 18.0–18.3, or is it only an advertising filter? We have not tested that variant and are not assuming it activates a profile. We are specifically trying to cover new users. Preserved authorization from an older non-ASK app version, an existing working bond, or authorization from a companion Watch app would not cover that case. We would appreciate an exact public API/configuration or clarification of the supported boundary before changing our production flow. References: https://developer.apple.com/documentation/accessorysetupkit/asaccessorysession https://developer.apple.com/videos/play/wwdc2024/10203/ https://developer.apple.com/documentation/bundleresources/information-property-list/nsaccessorysetupkitsupports No full device logs, device identifiers, proprietary source, or user data are attached.

Hello, does anyone know how to permanently disable the built‑in display in macOS 15 on iMac M1 programmatically or via the terminal? I’m facing a problem — the display cable is broken. As a result, not only does it work poorly, but there’s also severe overheating in the upper right part of the iMac. The warranty has expired, and I don’t have the funds to replace the display right now. So I’m looking for ways to disable the built‑in screen and work only with an external display. At the moment, I’ve found a way to disable the display after logging in, but before logging in, the screen gets hot, and in this mode I won’t be able to upgrade to the new operating system. The process is lengthy, and the screen will become significantly hot. Ideally, the built‑in display should be disabled during reboot and when upgrading to a new version of macOS, and an external display should be used as the main display.

PLATFORM AND VERSION iOS Development environment: Xcode Xcode 27.0, macOS macOS Golden Gate 27.0 Run-time configuration: iOS iOS 27.0 DESCRIPTION OF PROBLEM Environment: 1.I have a BLE hardware development board, The BLE broadcast name is "feature", Integrate an Apple Authentication 4.0 Coprocessor. The phone is iPhone 12 Pro Max, and the system is iOS 27 2.The source code of the app is from https://developer.apple.com/documentation/AccessorySetupKit/setting-up-and-authorizing-a-bluetooth-accessory. Modify the app's identifier from E56A082E-C49B-47CA-A2AB-389127B8ABE4 to F299FC19-5898-4F68-ACE6-E036ABE50781, that is Authenticated Accessory Capability Service of Accessory Authentication (BLE L2CAP). 3.descriptor.supportedOptions = [.bluetoothPairingLE, .bluetoothHID] Abnormal phenomenon： 1.ASKSample.app paired accessory name "feature" successful, but iPhone just connect accessory and read PSM characteristic every 10s, iPhone not send "LE Credit Based Connection Request - (PSM: 0x0080)". 2.I try set value of Authentication Channel PSM 7401DD11-3558-4459-98EE-371BBFC84C45 to [00, 80] or [80, 00], detailed packet capture of PacketLogger.app(from Additional_Tools_for_Xcode_27) is same, no "LE Credit Based Connection Request - (PSM: 0x0080)". 3.Detailed packet capture of Console.app will show error log "No authorized extension feature, missing services.txt". "NSInvalidArgumentException" is not report from my app. Question： 1."LE Credit Based Connection Request - (PSM: 0x0080)" is this automatically initiated by the iOS system? Is it necessary for the app to call the code peripheral.openL2CAPChannel(0x0080)? Does the app need to send RequestAuthSetup (0x5100)? 2.Is the code I provided sufficient to complete the testing of Accessory Authentication (BLE L2CAP) without any code modifications? Alternatively, could you provide a Demo app for me to test with Accessory Authentication (BLE L2CAP)? 3.The current Accessory Authentication (BLE L2CAP) testing process has not passed. I have provided two BLE packet captures and one iOS system packet capture to help identify where the problem lies. log: 1.search "No authorized extension feature, missing services" for error log. 2.20261014_Big-endian_parsing_PSM_Multiple_Read_PSM.pklg and No authorized extension feature, missing services.txt were captured simultaneously. The complete process from "October 14 10:49:10.631" to "October 14 10:49:11.723" in pklg includes connecting, reading PSM, and disconnecting. error flow of Console.app: ① DADaemonServer 错误 2026-10-14 10:49:11.243577 +0800 No authorized extension feature, missing services: DADevice: ID F202EAF6-578A-4F32-9FB9-668A12D3972F, name 'Blue Dice', Conn < Bluetooth >, btID 3d46f443-883a-ea17-3d63-ae00ec994cd4, btNm feature, flags AccessorySetup, BTPaired, type Hi-Fi Speaker, bluetoothSetupFinished yes, wifiAwareSetupInProgress yes, { DADeviceAppAccessInfo: com.example.apple-samplecode.ASKSample--SAMPLE-CODE-DISAMBIGUATOR-, ID F202EAF6-578A-4F32-9FB9-668A12D3972F, state Authorized, < Bluetooth >, Time 2026-10-14-02:48:46.371, disConfig asID 19D0C4AC-212F-4040-BA0A-EA8783422A0F, btSv [ BLE MFi ], com.example.apple-samplecode.ASKSample--SAMPLE-CODE-DISAMBIGUATOR-, flags 0x22 < BluetoothPairingLE BluetoothHID > } ② Server.LE 默认 2026-10-14 10:49:11.270649 +0800 Adding "needsMFiAuthentication4.0" tag to device "3D46F443-883A-EA17-3D63-AE00EC994CD4" ③ BTLEServer 调试 2026-10-14 10:49:11.282474 +0800 Received XPC message: <OS_xpc_dictionary: <dictionary: 0x7ba5048000> { count = 2, transaction: 1, voucher = 0x101282240, contents = "kMsgId" => <string: 0x7ba5019530> { string cache = 0x0, length = 16, contents = "MFiAccessoryAuth" } "kMsgArgs" => <dictionary: 0x7ba5039080> { count = 1, transaction: 0, voucher = 0x0, contents = "kPeerIdentifier" => <uuid: 0x7ba50194a0> 3D46F443-883A-EA17-3D63-AE00EC994CD4 } }> BTLEServer 默认 2026-10-14 10:49:11.282486 +0800 Performing MFI Auth for CBPeripheral UUID 3D46F443-883A-EA17-3D63-AE00EC994CD4 CoreBluetooth 调试 2026-10-14 10:49:11.282499 +0800 Sending synchronous XPC message CBMsgIdPeerHasTag: { kCBMsgArgDeviceUUID = "3D46F443-883A-EA17-3D63-AE00EC994CD4"; kCBMsgArgName = "needsMFiAuthentication4.0"; } ④ CBStackDeviceMonitor 默认 2026-10-14 10:49:11.375700 +0800 GATT device init completed: Device 3D46F443-883A-EA17-3D63-AE00EC994CD4 ⑤ CoreBluetooth 调试 2026-10-14 10:49:11.615127 +0800 Sending XPC message CBMsgIdServiceDiscoverCharacteristics: {kCBMsgArgDeviceUUID = "3D46F443-883A-EA17-3D63-AE00EC994CD4";kCBMsgArgServiceEndHandle = 48;kCBMsgArgServiceStartHandle = 46;kCBMsgArgUUIDs = ("MFi Team ID","MFi Protocol String","MFi Command","MFi Accessory Type","MFi Accessory Attributes","MFi Auth PSM");} ⑥ ASTCommon 信息 2026-10-14 10:49:11.707600 +0800 Reset -- (null) ASTCommon 调试 2026-10-14 10:49:11.707613 +0800 Removing devices: <NSIndexSet: 0xb0a5e8a79a88d37f>[number of indexes: 1 (in 1 ranges), indexes: (0)] ⑦ <缺少描述> 默认 2026-10-14 10:49:11.714044 +0800 *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[1]' *** First throw call stack: (0x184183190 0x183f00380 0x1840fbd9c 0x18417b628 0x100881008 0x10086de44 0x100867e54 0x20abe45d4 0x20abe4670 0x20aba75ec 0x20ab70b10 0x20ab7d454 0x20ab71394 0x1b25dfccc 0x1b25f9fb4 0x1b25e887c 0x1b25e9470 0x1b25ef278 0x1b25ef044 0x1841347a0 0x18412588c 0x1841267f4 0x1845efda8 0x1847ea4d4 0x100858b38 0x183f775b8) ⑧ Packet Logging 调试 2026-10-14 10:49:11.714955 +0800 LOG; 22.612049; 24399DE4-4BCF-44C4-BFC8-3D7636310B99_81C912B0-C4BD-4090-A9A5-51F6034678DF; Bluetooth LE; Event; DETACH; GenericMFi detached! ⑨ Server.LE.Security 默认 2026-10-14 10:49:11.717602 +0800 Removing temporary security keys for device 3D46F443-883A-EA17-3D63-AE00EC994CD4 Server.LE.Security 默认 2026-10-14 10:49:11.727792 +0800 Removing temporary IRK for device 3D46F443-883A-EA17-3D63-AE00EC994CD4 STEPS TO REPRODUCE 1.open ASKSample.xcodeproj, run ASKSample.app on iPhone. 2.click "Add Dice" on app, app will find accessory name "feature", click "Set Up", Accessory Paired successful. SUPPORT INFORMATION Did someone from Apple ask you to submit a code-level support request? No Do you have a focused test project that demonstrates your issue? Yes, I have a focused test project to submit with my request What code level support issue are you having? Problems with an Apple framework API in my app NAME AND APPLE ID OF APP ASK Sample All log in attached file.

Hello Apple Engineering Team, I am investigating a specific Apple Watch connectivity behavior. Devices: Apple Watch Series 7, watchOS 26.6 (release) Paired iPhone 17 Pro Max, iOS 27 beta 2 Observed behavior: the Apple Watch vibrated continuously for approximately 5–6 seconds. When the wrist was raised, a red "iPhone Disconnected" screen was visible. However, a subsequent iPhone sysdiagnose contained NRBTPipe[Disconnected 158825.34s], suggesting that the associated communication pipe had already been disconnected for roughly 44 hours before the sysdiagnose was captured — i.e., well before the observed alert. I would appreciate clarification on the following technical questions: What exactly triggers the red "iPhone Disconnected" screen on Apple Watch? Is it triggered immediately when Bluetooth connectivity is lost, or can it appear later? Does this screen automatically generate a haptic notification? Under what conditions could the user experience several seconds of repeated vibration? Does the alert depend only on the local Bluetooth connection, or does it also account for Wi-Fi/cloud connectivity? Could the local connection remain disconnected while the red screen appears substantially later? What does the internal NRBTPipe[Disconnected ...] duration represent? Does it correspond directly to the connectivity state used by the Watch UI? Is there any way to recover a historical watchOS sysdiagnose that may have been triggered using the Digital Crown and side button without a logging profile installed beforehand, particularly when the Watch and iPhone were not locally connected? I understand that some implementation details may be private. Even confirmation of the expected UI timing and haptic behavior would be extremely helpful. If Feedback Assistant is the preferred route, I am happy to file a report with logs attached. Thank you.

Summary Our app uses CBPeer.identifier in Core Bluetooth to identify BLE peripherals. For the same non-bonded BLE peripheral, we have observed the following behavior: On iOS 18, CBPeer.identifier did not change across OS updates or device reboots. On devices updated to iOS 27.0, the CBPeer.identifier of the same peripheral became a different value after the OS update. On iOS 27.0, we have also confirmed that CBPeer.identifier changes after a device reboot. API documentation: https://developer.apple.com/documentation/corebluetooth/cbpeer/identifier We would like to confirm whether this is a specification change in iOS 27 and whether it is intended behavior. Questions Is it intended behavior in iOS 27 that CBPeer.identifier for a non-bonded BLE peripheral changes after an OS update or device reboot? If this is by design, is there any documentation (release notes, technical documents, API reference, etc.) that describes this change? Under what conditions can the CBPeer.identifier of a non-bonded BLE peripheral change? (e.g., OS update, device reboot, resetting Bluetooth settings, reinstalling the app, after a certain period of time, etc.) If we need to keep identifying the same non-bonded BLE peripheral across reboots and OS updates, what implementation approach do you recommend? Any information would be greatly appreciated. Thank you.

Hi, Selecting Auto mode in the Home app on a Matter Room AC device results in Cool being sent over Matter. Off, Heat and Cool work correctly. The reverse also fails: selecting Auto from another ecosystem (e.g. Samsung SmartThings) goes out correctly over Matter, but the Home app shows Cool. The issue is specific to the Room AC device type — with the same device exposed as Thermostat, everything works. In the logs, the Home app parses the requested mode correctly and sends it to the home hub; on the hub side the logs show Cool going out over Matter. Filed as FB25164477 (logs and repro attached). Is this a known issue? Thanks!

I am developing a noncommercial graduation project for display color measurement with an iPhone Air. Is there a supported public API or entitlement for real-time chromaticity and illuminance readings from the built-in ambient light sensor? SensorKit's 24-hour data holding period does not fit this use. If this is unavailable, where should I submit an API enhancement request?

I recently updated my iPhone SE (2020) to the iOS 27 beta, and initially the experience was excellent. The phone felt noticeably faster and more responsive, and I was genuinely impressed with the update. However, after about a day of usage, I started experiencing a charging-related issue. One night, I left my phone connected to the charger before going to sleep when the battery was at 55%. The next morning, I found that the battery had dropped to 42% instead of charging. I checked all connections and confirmed that the charger, cable, and power source were properly connected. When I disconnected and reconnected the charger, the charging lightning bolt icon would briefly appear, then turn grey after about two seconds, and finally disappear completely a couple of seconds later. The phone would not charge. Assuming it might be a faulty charger or cable, I tested with: A different Apple charger A different Lightning cable The same issue persisted. Next, I connected the phone to my Mac. Surprisingly, it started charging, and Finder recognized the device normally. Over the next few days, the behavior became inconsistent: Sometimes the phone would charge. Sometimes it would not charge at all. Connecting to the Mac worked most of the time, but occasionally even that failed. I also noticed another unusual behavior: If I unplugged the Lightning cable from the iPhone and plugged it back in, the charging symbol would briefly appear. However, if I left the cable connected to the iPhone and unplugged/replugged only the USB end from the power adapter, there would be no response whatsoever—no charging sound, no charging icon, nothing. I cleaned the charging port, cable connectors, and charger contacts, but the issue remained. At that point, I realized the problem started immediately after installing the iOS 27 beta. To verify whether it was software-related, I restored the device back to iOS 26.5. After downgrading, the charging issue completely disappeared, and the phone began charging normally again with the same charger and cable. Based on my testing, this appears to be a software-related issue introduced in the iOS 27 beta rather than a hardware problem. I am posting this in case other iPhone SE (2020) users are experiencing similar charging behavior after updating to the beta. Device: iPhone SE (2020) Issue: Intermittent charging failure after updating to iOS 27 beta Status: Resolved after restoring to iOS 26.5

I have a reproducible Bluetooth audio fault on my MacBook Pro M3 Max and have narrowed it down as far as I can from user space. I have filed it as FB25169767. I am posting the data here in case it helps others with the same log lines, and in case an Apple engineer can say what to capture next. I used AI tools for this investigation: Claude to run the tests and analyse the logs, and ChatGPT for web research. I did the listening tests myself, and the outside sources quoted below were checked against the originals. My setup MacBook Pro M3 Max (Mac15,9), macOS 15.6.1 (24G90) Bluetooth controller: Broadcom BCM4388, firmware 22.5.542.2788 Sink: Creative T100 desktop speaker, Bluetooth 5.0, A2DP, SBC only Negotiated: SBC 44.1 kHz joint stereo, bitpool 52, 322 kbps, 5 frames x 117 B per packet every 14.51 ms, L2CAP MTU 672 The speaker is about 25 cm from the Mac, with line of sight. Wi-Fi is on 5 GHz. A Magic Trackpad is connected. Symptom I have heard audible gaps from this speaker in every app for years. My AirPods and Sony WH-1000XM4 on the same Mac do not glitch. What bluetoothd reports for my speaker A2DP LinkQualityReport, one line a second while streaming: A2DP LinkQualityReport: Handle = 11 ReTx = 75.8% (135 / 178), NAK = 0, NoSync = 135, TxPwr = 7 dBm, RSSI = -46, {50,75,90}th Noise = {-102,-102,-101} for 29 ch, 2EDR pkts = 138, 3EDRTx pkts = 0, HDR4Tx pkts = 0, HDR8Tx pkts = 0, ... CoexDenial = 0, CoexRequest = 0, ... TxFlush pkts = 0, Tx2Flush pkts = 0, rate = 322 kbps Flow off = 0 Over 11,808 reports from my normal use (3.3 h of streaming, 12 to 13 October 2026): Speaker (SBC) AirPods (AAC), earlier capture ReTx median 56.6% (p10 50.5%, p90 63.0%) median 8.1% Retransmission cause all NoSync, NAK 0 mostly NoSync RSSI median -38 dBm about -47 dBm Noise about -100 dBm similar Packets on air about 195/s, all 2-EDR (about 2.8 attempts per 14.51 ms audio packet) about 38/s, mostly HDR TxPwr, AFH channels 7-8 dBm, about 44 8 dBm, about 45 "Link Adaptive Packet type support" 0 1 Packet drops 17.6 a minute (25.8 a minute on another day) 0 while streaming This is what the drops look like in my log: [Server.A2DP] A2DP packet flushed: L2CAP (chip) flush occured. Current sequence=28, timestamp=40557459 [Stack.L2CAP] Write in progress (status=65535) [Server.A2DP] A2DP packet flushed: Audio Queue full, remove oldest and insert sequence=29 (latest), timestamp=40557479 Every one of the 2,670 "Audio Queue full" drops in that period comes with an L2CAP "Write in progress (status=65535)" on the same thread in the same millisecond, just before it. The other 795 drops are "L2CAP (chip) flush occured". So most of the lost audio is discarded on the host when the previous write to the controller has not completed yet. Other details: The report's TxFlush pkts, Tx2Flush pkts and slot counters are 0 in every report for this link, also in seconds with a logged chip flush. Flow off is above 0 in only 19 of 2,835 seconds (one capture), so the controller's ACL buffers are not usually full. bluetoothd logs "Setting flush timeout, chipId:23" and "Dynamic Latency settting flush timeout to 200 ms" at AirPods events, never at this speaker's stream start. Audio Timesync for this link: "Audio Delivery Average Time" 9750 to 16750, "Pending Packets" 18 to 27, "Queue depth" up to 8. Second symptom: CoreAudio overloads With this speaker, bluetoothd logs Initiate Audio Delivery Speed Change (0.9x or 1.1x) about once a second. With AirPods it happens only at stream start. Each change shifts the HAL clock: safety_violation_time_gap median 7.9 ms, max 20.9 ms (1,645 reports). Any client with a 256-frame IO buffer (Chrome Web Audio uses 256 below 96 kHz) then logs HALS_OverloadMessage: Overload possibly due to safety violation 50 to 100 times a minute. I ran a silent test: a CoreAudio client playing digital zeros to the speaker, 40 s per buffer size. HAL buffer Overloads/min ReTx 256 frames 49.5 60.5% 512 frames 0 58.0% 1024 frames 0 58.0% A bigger buffer stops the overloads but not the packet drops. Control experiment: a non-Apple sender to the same speaker I plugged a USB Bluetooth 4.0 dongle (Broadcom BCM20702A0) into the same Mac. macOS attaches no Bluetooth driver to it, so I could drive it from user space with BTstack (port/libusb, a2dp_source_demo). Same desk, same distance, same SBC bitpool 52 at 14.51 ms intervals. 2 min 24 s of audio, and I listened to all of it: 9,892 of 9,892 media packets completed, no flush, no audible gap. Packets in flight: median 2, max 5. Send to Number Of Completed Packets: median 27 ms, p95 48 ms, under 70 ms in steady state. BTstack sets no automatic flush timeout and never discards late packets. So my speaker's receiver and my room are fine. The fault is in Apple's transmit path for this link: bluetoothd, the BCM4388 firmware, or the link policy between them. This test cannot say which. What I ruled out Nothing I changed moved ReTx from 50 to 60%, and it does not follow RSSI between -36 and -56 dBm. Bluetooth off/on (ReTx 57.8% before, 58.8% after), re-pairing (64% after) Trackpad traffic (0 reports/s, ReTx 56%), Wi-Fi coexistence (5 GHz, CoexDenial 0) Lid open, nearby LED lamps unplugged, monitor USB-C cable unplugged, Mac moved 2 m away Audio content: digital silence behaves the same as music I have not yet tried a fresh boot (the Mac had been up 116 days), macOS 15.8.1 or a PacketLogger capture. Related Asahi Linux found that Apple's Broadcom controllers (BCM4377/4378/4388) need vendor command 0xFC57 (ACL priority) for clean A2DP, and that the whole audio connection must stay high priority while it carries audio: one low-priority packet, such as a volume change, causes a dropout (netdev list, 15 April 2026, "[PATCH v2] Bluetooth: Add Broadcom channel priority commands"). An earlier capture showed macOS sending 0xFC57 plus vendor commands 0x1DD, 0x205 and 0x22D per connection at playback start. A similar write-up with the same three log lines, ReTx 51.4% at -36 dBm, but triggered by sleep/wake and cured by Bluetooth off/on (which does not help me): https://note.com/honest_kudu5817/n/n7e8a12aecb13 Questions Does macOS apply a different link policy to a non-Apple SBC sink than to AirPods (ACL priority, automatic flush timeout, packet types, Dynamic Latency)? Does "Link Adaptive Packet type support=0" mean this link is excluded from something? Is 0xFC57 held for the whole stream, or dropped around AVRCP traffic such as volume changes? What does NoSync count exactly, and why would it be more than half of all transmissions at -40 dBm? Is there anything I can capture beyond PacketLogger with the Bluetooth logging profile that would help the Bluetooth team? Has anyone else seen "Write in progress (status=65535)" paired with "Audio Queue full" on a steady link like this, and found anything that changes it? I am happy to run more tests or share more logs.

Hi there, I am working on a (Mac Catalyst) HomeKit my own private application, which observes different characteristics of different accessories. This works (also thanks to the advice here, thanks again to all who helped!) like a charm. Now I've found that one of my outlets which is connected through Matter supports power consumption (in Home.app), but there is no characteristic for that, all I can see is its power state. Self-evidently, access to the consumption would be something Matter-specific. At this moment, to save time, I'd rather not study the complete Matter kit in detail if it can be dodged for this particular very limited goal. Is it possible just as simply as possible to read in (if readable) and observe (if observable) those extra Matter characteristics (if any) for an HMAccessory, presumably through its matterNodeID somehow? I'd be grateful for a sample code, if some is available (preferably ObjC, but of course Swift better'n nothing). Thanks a lot!

I’m using an iPhone 15 Pro Max on iOS 27, with the Action Button assigned to the flashlight. The problem is that the Action Button only activates the flashlight when the front of the phone is unobstructed. If the phone is facing away from me, against clothing, partly covered, or otherwise detected as being in a pocket, iOS ignores the Action Button press. I understand why proximity/pocket detection exists to prevent accidental activation, but for the flashlight this behaviour is inconvenient. The flashlight is one of the functions where a physical button is especially useful because I often want to activate it without looking at or repositioning the phone. I also tried assigning a Shortcut that toggles the flashlight instead of using the native Flashlight Action Button option, but the same restriction still applies. Steps to reproduce: Assign Flashlight to the Action Button. Lock the iPhone. Hold the phone normally and cover the front/proximity sensor, or place the phone screen-down. Press and hold the Action Button. The flashlight does not activate. Uncover/turn the screen toward you and try again — it works. Expected behaviour: An intentional press-and-hold of the Action Button should be able to activate the flashlight regardless of phone orientation or proximity sensor state. At minimum, it would be useful to have an option such as: “Allow Action Button while proximity sensor is covered” or an exception specifically for the flashlight. The current behaviour makes the Action Button significantly less useful as a physical flashlight switch.

I’m developing a macOS app that reads a wired controller and publishes a generic BLE HID gamepad for an iPhone. BLE communication works, but iOS does not expose the device through GameController. I’m looking for guidance on supported device-identity publication and controller-admission requirements. Environment Apple Silicon MacBookPro17,1: macOS 27.0, build 26A428 iPhone 15 Pro Max: iOS 27.0, build 24A437 Xcode 27 Peripheral implemented using CBPeripheralManager What works The iPhone can connect, perform dynamic characteristic reads, and read encryption-required characteristics using the retained pairing. It discovers the application’s HID service and reads its Report Map, HID Information, Report Reference, and Input Report. The descriptor in the iPhone’s system HID record matches the application’s remotely read report map byte-for-byte. The peripheral also receives an input subscription, although I cannot independently identify the subscribing consumer. What fails An independent GCController.controllers() observer remains empty. During the recorded HID initialization, the iPhone logs: Un-authenticated game controller device attached Start failed: 0xe00002bc IOHIDEventDriver start failed. For the same registry device, gamecontrollerd records: vendorID = 0 productID = 0 version = 0 manufacturer = 'Apple Inc.' product = '[Mac device name]' transport = 'BluetoothLowEnergy' I am not assuming that “Un-authenticated” identifies a specific authentication requirement. I would like to understand which supported admission requirement is unmet. Device Information observations The iPhone’s CoreBluetooth discovery exposes two distinct Device Information service instances: System service Observed UUID: 180A Manufacturer: Apple Inc. Model: MacBookPro17,1 No PnP characteristic exposed by successful all-characteristic discovery Application service Observed UUID: 0000180A-0000-1000-8000-00805F9B34FB Manufacturer: PS3 Bridge Model: BLE Gamepad Prototype PnP bytes: 02 00 00 01 00 00 01 The application publishes expanded Bluetooth-base UUIDs. I understand these represent the same assigned UUIDs; I am preserving the observed representations because I have not established whether every host component handles them identically. The application PnP value represents vendor-ID source 2, vendor 0, product 1, and version 0x0100. The system HID record therefore does not simply reflect that value unchanged. The duplicate-DIS layout also appears inconsistent with the unique primary DIS expected by HOGP. I have not established that this causes the driver rejection. Questions Is there a supported macOS API or architecture for publishing a coherent BLE HID device identity when macOS already exposes its own Device Information service? How does iOS select DIS/PnP information when constructing a system HID device in this arrangement? Is a generic BLE HID gamepad published through macOS CoreBluetooth a supported path to iOS GameController recognition? If so, what additional profile, identity, or authentication requirements apply? What supported diagnostics would distinguish an identity-selection problem from a separate controller-admission requirement? Available evidence I have diagnostic source, corrected per-service-instance inventories, and redacted phone logs available. I also have a small standalone CoreBluetooth publication reproducer. It is reduced and has not been validated as independently reproducing the full bridge’s controller rejection. A later connection-only observation reused an existing shared Bluetooth link and still showed zero controllers. I am not treating that as a fresh HID initialization or admission attempt. I’m seeking a supported implementation path without private APIs, Bluetooth daemon modifications, or changes to system security.

We receive live relative-altitude updates from CMAltimeter.startRelativeAltitudeUpdates(to:withHandler:) on iPhone. CMAltitudeData inherits CMLogItem.timestamp, which the documentation describes as the time when the item is valid and as seconds since device boot. We need to determine whether a pressure measurement's event time falls inside an application operation bounded by a supported monotonic clock. Could Apple clarify the supported contract for CMAltitudeData.timestamp on iOS? Does CMAltitudeData.timestamp use the same epoch and rate as mach_absolute_time(), DispatchTime.uptimeNanoseconds, CACurrentMediaTime(), or ProcessInfo.systemUptime? If only some are compatible, which ones? Does it advance or pause during device sleep, device lock, application suspension, and background execution? In particular, are its sleep/suspension semantics guaranteed to match any of the clocks above? Is there a supported API for converting CMLogItem.timestamp to a host CMClock/Mach time, or for sampling “now” in the exact same clock domain used by CMAltitudeData.timestamp? Are the answers contractual across supported iPhone hardware and iOS releases, or are they implementation details that applications should not rely on? If direct comparison is not supported, what Apple-supported clock or conversion mechanism should an application use to compare a CMAltitudeData event time with two application-side monotonic operation boundaries? The question concerns clock semantics only. A minimal reproducer can be supplied if requested, but no application identifier, production data, sensor values, or user data is required to answer it.