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.

We are investigating a wireless CarPlay connection failure between our vehicle headunit and iPhone, and have identified a suspicious pattern in the carkitd pairing flow through analysis of iPhone sysdiagnose logs. As we have been unable to fully interpret certain behaviors on our own, we would greatly appreciate any guidance or clarification Apple could provide. The original sysdiagnose log file is available upon request. Failure case — UTC 07:14 07:14:25 [carkitd] Transitioning: [started] → [Bluetooth confirmation] 07:14:26 [carkitd] Transitioning: [Bluetooth confirmation] → [Bluetooth contacts sync] 07:14:27 [carkitd] Transitioning: [Bluetooth contacts sync] → [waiting on messaging connection] 07:14:32 [carkitd] Consolidated ... CARiAPAuthComplete payload for event type 5 07:14:32 [accessoryd] sending EAAccessoryArrived to carkitd for accessory: Ioniq5566 07:14:32 [carkitd] updated partial session (null) (hasAccessory = NO) * CARCarKitWirelessPairingCreatedEvent not observed * [connect CarPlay] not entered 07:14:57 [carkitd] Transitioning: [waiting on messaging connection] → [dismiss/finished] ← Terminates ~25 sec later without sending CarPlayAvailability Success case (Ioniq5) — UTC 07:12 (same sysdiagnose file, same iPhone) 07:12:05 [carkitd] Transitioning: [Bluetooth contacts sync] → [waiting on messaging connection] 07:12:12 [carkitd] CARCarKitWirelessPairingCreatedEvent received 07:12:14 [carkitd] Transitioning: [waiting on messaging connection] → [connect CarPlay] 07:12:18 [carkitd] sending CarPlayAvailability {wireless: YES BT: <private>} ← Wireless CarPlay established successfully The only observable difference between the two cases is whether CARCarKitWirelessPairingCreatedEvent occurs. Could you help us understand what conditions prevent this event from being generated, and whether there is a fallback path into [connect CarPlay] when it is absent? Any insight would be greatly appreciated. Thank you for your time.

Hello Apple Developer Team, We are observing a BLE connectivity issue in our application BlueDiamond Mobile Elite after upgrading devices to iOS 27 Public Beta. Environment App: BlueDiamond Mobile Elite Platform: iOS 27 Public Beta Framework: CoreBluetooth Device Type: iPhone BLE Peripheral: Access control/BLE reader Testing Status: BLE scanning works correctly. Reader discovery works correctly. Connection establishment succeeds. Service and characteristic discovery complete successfully. Issue occurs during credential transmission. Problem Description After connecting to a BLE reader, our application sends mobile credentials to the reader using CoreBluetooth. The workflow is: Scan for BLE readers. Discover target reader. Connect to reader. Discover services and characteristics. Start credential transfer. BLE connection disconnects unexpectedly during or immediately after the credential write operation. The disconnect occurs before the credential transaction completes successfully. Observed Behavior BLE scanning is functioning normally on iOS 27 Public Beta. The reader is discovered without issues. Connection is established successfully. Credential provisioning/credential write operation triggers the problem. centralManager(_:didDisconnectPeripheral:error:) is invoked after the credential transfer attempt. The credential is not successfully delivered to the reader. Expected Behavior The BLE connection should remain active throughout the credential provisioning process and disconnect only after the transaction is completed or when explicitly terminated by the application. Additional Information The same credential issuance flow worked correctly on previous iOS versions. We have already addressed another iOS 27 compatibility issue related to QR code access by updating to Apple's recommended APIs. We are currently investigating whether the BLE disconnection is caused by: Changes in CoreBluetooth behavior in iOS 27 Public Beta. MTU/write packet handling. Write-with-response versus write-without-response behavior. Peripheral firmware compatibility. Credential payload size or transfer timing. Questions Are there any known CoreBluetooth regressions or behavior changes in iOS 27 Public Beta related to characteristic writes or BLE credential provisioning? Has anyone observed unexpected peripheral disconnects during write operations on iOS 27 Public Beta? Are there any recommended changes for applications performing secure credential transfers to BLE peripherals? Any guidance would be greatly appreciated.

Environment: iPadOS 27 Beta (Developer Beta) iPad with Bluetooth Classic (iAP2/ExternalAccessory) + BLE active session App uses UIKit, WKWebView, scene-based lifecycle Problem: When the user invokes the new Siri AI by long-pressing the power button while our app is in the foreground with an active Bluetooth Classic session, we observe: No scene lifecycle callbacks fire — no sceneWillResignActive, no sceneDidEnterBackground, nothing. We confirmed by logging every UISceneDelegate method. Main thread / data processing threads are starved for ~2 seconds, causing a backlog of incoming Bluetooth data. Our real-time data processing latency jumps from ~105ms to over 2,300ms within 2 seconds of Siri activation. CADisplayLink / requestAnimationFrame callbacks show a ~935ms gap coinciding with the Siri overlay appearance, then irregular intervals afterward. The Bluetooth Classic transport (ExternalAccessory/iAP2) remains physically connected throughout — the issue is purely host-side processing starvation. What we've ruled out: BLE link degradation: firmware-side diagnostics confirm 100% data delivery, 0 lost packets during the incident Memory pressure from our app: our process memory stays flat; system-available memory drops ~14 units externally Questions: Is the absence of sceneWillResignActive when Siri AI activates on iPadOS 27 intended behavior, or a beta bug? The new UIApplication.systemPrefersReducedResourceUsage property (iPadOS 27 beta) — is this intended to signal system overlays like Siri consuming resources? Does the corresponding systemPrefersReducedResourceUsageDidChangeNotification fire when Siri activates? Are there recommended patterns for apps with real-time Bluetooth data processing to maintain thread priority during system overlays? We currently use default QoS for our data processing dispatch queues. The processing starvation causes the waveform display to degrade (appears as a connectivity issue to the clinician) even though the wireless link is healthy. We need either: A notification that a system overlay is active, so we can adjust our UI accordingly Guidance on maintaining processing priority during Siri AI activation Any community insight on workarounds would be highly appreciated. Thanks.

We urgently need a response from the relevant authorities

We are investigating a wireless CarPlay connection failure between our vehicle headunit and iPhone, and have identified a suspicious pattern in the carkitd pairing flow through analysis of iPhone sysdiagnose logs. As we have been unable to fully interpret certain behaviors on our own, we would greatly appreciate any guidance or clarification Apple could provide. The original sysdiagnose log file is available upon request. Failure case — UTC 07:14 07:14:25 [carkitd] Transitioning: [started] → [Bluetooth confirmation] 07:14:26 [carkitd] Transitioning: [Bluetooth confirmation] → [Bluetooth contacts sync] 07:14:27 [carkitd] Transitioning: [Bluetooth contacts sync] → [waiting on messaging connection] 07:14:32 [carkitd] Consolidated ... CARiAPAuthComplete payload for event type 5 07:14:32 [accessoryd] sending EAAccessoryArrived to carkitd for accessory: Ioniq5566 07:14:32 [carkitd] updated partial session (null) (hasAccessory = NO) * CARCarKitWirelessPairingCreatedEvent not observed * [connect CarPlay] not entered 07:14:57 [carkitd] Transitioning: [waiting on messaging connection] → [dismiss/finished] ← Terminates ~25 sec later without sending CarPlayAvailability Success case (Ioniq5) — UTC 07:12 (same sysdiagnose file, same iPhone) 07:12:05 [carkitd] Transitioning: [Bluetooth contacts sync] → [waiting on messaging connection] 07:12:12 [carkitd] CARCarKitWirelessPairingCreatedEvent received 07:12:14 [carkitd] Transitioning: [waiting on messaging connection] → [connect CarPlay] 07:12:18 [carkitd] sending CarPlayAvailability {wireless: YES BT: <private>} ← Wireless CarPlay established successfully The only observable difference between the two cases is whether CARCarKitWirelessPairingCreatedEvent occurs. Could you help us understand what conditions prevent this event from being generated, and whether there is a fallback path into [connect CarPlay] when it is absent? Any insight would be greatly appreciated. Thank you for your time.

I’m delighted with the introduction of new color folders. Although, I can’t help but wonder why we still need both color folders and tags. Aren’t the color folders sufficient for our needs?

iPhone 16 Pro, iOS 26.5 (23F77), Nissan Sentra 2022, USB-C wired CarPlay. CarPlay fails every attempt despite the iAP2 handshake completing successfully. Same cable + same car works with a different iPhone. After digging through sysdiagnose logs I found the root cause in audiomxd. The head unit's Bluetooth MAC (BC:42:8C:B8:06:AF) is permanently stored in the PVM as HeadphonesBT: PVM: Route [58] = HeadphonesBT~BC:42:8C:B8:06:AF This causes FigRoutingManagerProcessCustomizedRouting to return: isPortOfTypeCarPlayAtIndex = NO modelID = BTHeadphones4236,19521 And vaemProcessCarPlayCustomizedRouting never adds a starkPort: portsToAdd[0] = AirPlayHandoffDevice portsToAdd does NOT contain a starkPort Without a starkPort the audio routing never activates. The endpoint gets published under endpointManager=Bluetooth as BluetoothHFPInput/Output instead of CarPlay. Disconnect follows with errors -16723 and -16617. This survives Forget Device, Forget Car, Reset Network Settings, and reboots. The only thing that clears it is Reset All Settings. Two questions: Is there a supported way to purge audiomxd's PVM for a specific MAC address without Reset All Settings? 2. Is BTHeadphones4236,19521 a known misclassification for Nissan head units in iOS 26? Sysdiagnose attached to Feedback Assistant report FB22815215.

After hardware and mobile phone hid mode pairing, the first connection is successful, after a while disconnect and reconnect,APP monitoring Bluetooth error NSLocalizedDescription = "Peer removed pairing information"; Failed to connect Hardware engineers detect the pairing information and find that the local pairing information of the iPhone has changed, which is a non-mandatory phenomenon

https://developer.apple.com/feedback-assistant/profiles-and-logs/ There is no iOS profile in this link.

Hello Apple Developer Support, We are observing inconsistent behavior with push notification sounds routing to Bluetooth / external speakers. Our app sends push notifications with a custom sound file using the sound parameter in the APNs payload. When an iPhone is connected to a Bluetooth speaker or headphones: On some devices, the notification sound plays through the connected Bluetooth/external speaker. On other devices, the notification sound plays only through the iPhone’s built-in speaker. We also tested with native apps like iMessage and noticed similar behavior — in some cases, notification sounds still play through the phone speaker even when Bluetooth is connected. Media playback (e.g., YouTube or Music) routes correctly to Bluetooth, so the connection itself is functioning properly. We would like clarification on the following: Is this routing behavior expected for push notification sounds? Are notification sounds intentionally restricted from routing to Bluetooth in certain conditions (e.g., device locked, system policy, audio session state)? Is there any supported way to ensure notification sounds consistently route through connected Bluetooth/external speakers? The inconsistent behavior across devices makes it difficult to determine whether this is by design or a configuration issue. Thank you for your guidance.

Hello Apple Developer Community, I'm developing a cross-platform app using Flutter and the flutter_beacon library to handle iBeacon detection on iOS. My goal is to wake up the app in the background when it's in a killed/terminated state upon entering/exiting beacon regions, allowing for BLE communication (e.g., ranging or connecting to beacons). I've configured the necessary Info.plist keys for always location access and background location modes, and it works partially for single regions, but I have some specific questions/issues regarding reliability and limitations: Background Execution Time After Wake-Up: When the app is woken in the background by a region monitoring event (enter/exit) from a killed state, approximately how much time (in seconds) does iOS allocate for the app to run before suspending it again? Is this sufficient for performing BLE operations like ranging beacons or establishing a short connection, or are there stricter limits in terminated wake-ups compared to standard background modes? Monitoring Multiple iBeacons with Unique Identifiers: I need to monitor multiple iBeacon devices, each with potentially different UUIDs, majors, and minors. Can I add and monitor up to 20 regions simultaneously, each with a unique string identifier? If multiple beacons (from different regions) enter their respective ranges at around the same time, will the app receive separate callbacks for each region/identifier, or is there coalescing/prioritization that might cause only the last-added identifier to trigger notifications/events? Reliability in Killed State: In a fully killed state (e.g., force-quit via app switcher), does iOS reliably relaunch the app in the background for region monitoring events? Are there any known caveats, such as requiring specific hardware (e.g., iPhone models with certain Bluetooth chips) or iOS versions (targeting iOS 14+), and how does this interact with Flutter's background execution handling via the flutter_beacon library?

Is there any information for developer about notification forwarding which is published in iOS 26.3? how to use it ?

Hello Apple Bluetooth team, We are developing a real-time call translation system that streams raw PCM audio over BLE between iPhone and custom earbuds. This works reliably on iPhone 14 / 15 / 16, but on iPhone 17 (Bluetooth 6, N1 chip) we see severe and repeatable BLE packet loss, affecting both microphone uplink and TTS downlink. Our audio stream 16 kHz, 16-bit mono PCM 20 ms frames (~640 bytes) continuous bidirectional BLE streaming What happens on iPhone 17 BLE packets are frequently dropped entire audio frames are missing results in ASR gaps and broken TTS playback occurs even with strong RSSI and no RF interference Same firmware, same BLE protocol, same MTU and connection interval work normally on older iPhones. Questions We would like to know: Did Bluetooth 6 / N1 change BLE throughput, buffering, or scheduling? Are there new limits on sustained notify / write-without-response traffic? Is BLE audio now arbitrated differently against Wi-Fi / A2DP on iPhone 17? Is BLE still expected to support low-latency continuous audio streaming on iPhone 17, or is this no longer a safe assumption? Any guidance or new best practices would be greatly appreciated. Best regards, Valenti Zhang

My watch APP needs to keep Bluetooth connected with peripherals whether it is in the foreground or background, but the results of my test show that the connection in the background is very unstable, sometimes you can keep the Bluetooth on for a day, but sometimes it will be disconnected 50 times a day, and every time it is disconnected, I will immediately initiate a reconnection, it is certain that there is no problem with the peripheral Bluetooth, because I have another iOS device that has been stably connected to the peripheral, I want to know what causes this instability, and if there is any solution, if someone can provide relevant advice, I will be very grateful

Hi Team, I want to perform bluetooth advertising (no need to pair) from a macOS machine even before the user login to the macOS(i.e before user provide password and submit). Is there a way to achieve this?

When my Bluetooth peripheral device has both HID and MIDI services, the iOS Bluetooth host repeatedly sends different "Control Opcode: LL_CONNECTION_UPDATE_IND" to the peripheral, updating approximately every 100ms. The Bluetooth peripheral cannot handle such high-frequency update requests and typically disconnects with an error 0x28. My Bluetooth device uses the NRF52832 chip, and I have communicated with NORDIC and replicated this issue. This problem only occurs on iOS 26; it does not happen on earlier versions. I think it might be caused by the HID service in iOS requesting faster connection parameters for low latency, which then gets erroneously reverted for an unknown reason, leading to repeated competition and entering into a deadlock. Here is the communication record with NORDIC: https://devzone.nordicsemi.com/f/nordic-q-a/124994/ios-26-bluetooth-disconnect-issues This is the screenshot captured using the Bluetooth sniffer:

I am using a Raspberry Pi 5 (BLE 5.0) to read sensor data and send it via D-Bus and BlueZ to a Flutter application (flutter_blue_plus) for both iOS and Android. The goal is to display these real-time sensor updates directly on the device. On Android, the data transmission is immediate and the real-time visualization is extremely smooth and fast. However, on iOS, both BLE write and notification commands appear with noticeable latency—not only in real-time displays, but also when comparing ordinary notification feedback between the Raspberry Pi terminal and the iOS app. It seems that iOS buffers several BLE packets internally and then dispatches them in batches, which always introduces an additional delay. Additional setup details: I sample and transmit data every 25ms, sending binary packets of 20 bytes (length shouldn’t be a limiting factor). On the iOS side I am using an iPhone 15 Pro with iOS 18.6.2 (BLE 5.3). The Raspberry Pi (using btmon for logging) confirms after connection setup that the connection interval is fixed at 30ms (and cannot be changed). I have tried sending BLE packets every 30ms so that exactly one packet arrives per interval, but this made no difference—the latency and batch delivery remain. Interestingly, faster transmission rates (e.g. sending every 10ms) make the real-time display look smoother on iOS, but the guaranteed overall system latency does not improve. Also these methods used: write-without-response, using app in release modus (no debugging) Is there anyone familiar with this problem or a potential solution? Or is iOS simply not optimized for true real-time BLE data streaming and visualization? Any pointers, technical insights or workarounds would be greatly appreciated.

First, our app communicates with our blood glucose monitor (CGM) using Bluetooth Low Energy (BLE). On an iPhone 14 Pro with iOS 26.0.1, Bluetooth communication works properly even when the app is in the background and locked. Even if the phone and CGM are disconnected, the app continues to scan in the background and reconnects when the phone and CGM are back in close proximity. It won't be dormant in the background or when the screen is locked. This effectively ensures that diabetic users can monitor their blood glucose levels in real time. However, after using iOS 26.0.1 on the iPhone 17, we've received user feedback about frequent disconnections in the background. Our logs indicate that Bluetooth communication is easily disconnected when switching to the background, and then easily dormant by the system, especially when the user's screen is locked. This situation significantly impacts users' blood glucose monitoring, and users are unacceptable. What can be done?

[sysdiagnose_2025.10.01_18-29-27+0800_iPhone-OS_iPhone_23A341] I got sysdiagnose from my app user.He can't pair his bluetooth peripheral. in the sysdiagnose,I found this: device AC:7A:94:85:47:F4 is already paired, with a different irk (old:F5 C9 4F 5A 4E BE D0 20 0A 1F F7 DC 3A 89 E0 3A new 4A 8A 00 4C FF D0 CE 7B 61 13 FA B3 84 F4 65 29 ). Unpair first and then restart pairing. (status=65535) but there is no device in his iphone's SYSTEM BLUETOOTH PREPHERAL LIST. I don't know how to delete the irk info when you can't find it in SYSTEM BLUETOOTH PREPHERAL LIST. PLEASE answer me. THANKS.