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?

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.

Hi, Does anyone know if Apple has released the SDK to enable 2K streaming in HomeKit for doorbells/cameras? I've not seen anything posted so far, wondered if I've missed it. Thanks

We use ExternalAccessory to talk to a smart card, i.e. a YubiKey 5Ci, over Lightning. On iOS 27.0, most EASession objects we open are unable to receive. NSStreamEventHasBytesAvailable never fires on the input stream and not one byte arrives, yet the session reports no problem anywhere. Environment iPhone 11, iOS 27.0 build 24A437 (public release), YubiKey 5Ci on Lightning, protocol com.yubico.ylp. What we see on an affected session both streams streamStatus 2 (NSStreamStatusOpen) streamError on both nil NSStreamEventOpenCompleted fires on both hasSpaceAvailable before write YES write:maxLength: returns 18 of 18 NSStreamEventHasSpaceAvailable fires NSStreamEventErrorOccurred never NSStreamEventEndEncountered never NSStreamEventHasBytesAvailable never fires inputStream.hasBytesAvailable false on every poll over 10 s Everything reports success. Only the reply is missing. Behaviour A healthy session replies in single digit milliseconds. An affected one returns nothing at all, ever. The condition is set when the session is created and never changes. Opening another session on the same accessory is an independent roll of the dice. Quitting and relaunching the app does not help. Only physically detaching and reattaching the key does, after which connectionID increments and the next session works. 15 of 25 sessions affected on 24A437. Also 9 of 20 on the 24A5430a beta, so it predates the public release. Already ruled out Not a late reply, we waited 10 s. Not a missed event, we polled hasBytesAvailable directly about 200 times per failure. Not a leaked session, teardown is instrumented and every session deallocates exactly once. Not the hardware, another app on the same phone and key reads its serial and firmware every time, and that app opens one session and never closes it. The USB C interface of the same key, via CryptoTokenKit, never fails. Questions Is there any supported way to tell at creation time that an EASession input stream will not deliver data? Nothing we can read distinguishes the two cases. Is repeatedly creating and releasing EASession objects for the same accessory and protocol supported, and is any teardown step needed beyond clearing the delegates, closing the streams, removing them from the run loop and releasing the session? Is there a supported way to recover without asking the user to unplug the accessory?

On our telecommunication platform, D@niel mobile app, used for video meetings in education, training, we are able to activate two cameras simultaneously on Android devices using our D@niel software based on open source Bigbluebutton software. However, we haven't been able to do this on iPhones or Ipad so far. Will the new iPhone Duo allow us to enable dual-camera during a D@niel session call meeting, just like on Android. Please, watch the YouTube link. https://youtu.be/dwcmYZxuhD4?is=xVvkYvDxUrwJZWkn