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.

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.

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.

Using an iPhone Pro 12 running iOS 26.0.1, with AirPods Pro 3. Camera app does capture video with what seems to be "Studio Quality Recording". Am trying to replicate that SQR with my own Camera like app, and while I can pull audio in from the APP3 mic, and my video capture app is recording a 48,000Hz high-bitrate video, the audio still sounds non-SQR. I'm seeing bluetoothA2DP , bluetoothLE , bluetoothHFP as portType, and not sure if SQR depends on one of those? Is there sample code demonstrating a SQR capture? Nevermind video and camera, just audio even? Also, I don't understand what SQR is doing between the APP3 and the iPhone. What codec is that? What bitrate is that? If I capture video using Capture and inspect the audio stream I see mono 74.14 kbit/s MPEG-4 AAC, 48000 Hz. But I assume that's been recompressed and not really giving me any insight into the APP3 H2 transmission?

Hello, I am working on a Braille keyboard by using HID approach. Current the device works with iPhone 11 and SE3. However, when tested in iPhone 6s with iOS 15, although the device can be connected and recognized as Braille device in VoiceOver screen, the phone shows no response to key press report. Would there be any requirement at points such as HID descriptor for iPhone 6s support on Braille device? If iPhone 6s does not support such devices, what is the minimum system requirements? Thank you!

When establishing a Bluetooth connection and subscribing to feature values, the log shows a subscription failure with the error: did fail to update notification state: The handle is invalid.