Hi All, In continuation of this thread https://developer.apple.com/forums/thread/804439 I want to perform data upload after getting it from the BLE device. As state restoration wake should not deal with data upload i though of using a processing task to perform the data upload. So the flow will be something like: Connect to device -> listen to notification -> go to background -> wake from notification -> handle data download from ble device -> register processing task for data upload -> hopefully get the data uploaded From reading about processing task i understand that the task execution is completely handled by the OS and depends on user behaviour and app usage. I even saw that if the user is not using the app for a while, the OS might not even perfoirm the task. So my quesiton is: does state restoration wakeup and perfroming data dowloads in the backgound considered app usage that will increase the likeluhood the task will get execution time? Can we rely on this for a scenario that the user opens the app for the first time, register, onboard for ble, connect to devie and then put it in the background for days or weeks and only relying on state restoration and processing tasks to do their thing? Sorry for the long read and appreciate your support! Shimon

When an iOS device is connected to a Bluetooth accessory that utilizes the Hands-Free Profile (HFP), we are encountering an incorrect audio routing behavior specifically for system notification tones. Accessory Connected: The iOS device is successfully connected to a Bluetooth accessory (specifically, a WM500 device) using the HFP profile for voice communication. Voice Audio: Audio streams related to phone calls or voice communication (using the HFP/SCO link) are correctly routed to the WM500. Notification Tones Issue: System notification tones, which are played using the tonetype.systemsounds API, are not being routed to the connected HFP accessory (WM500). Instead, they are incorrectly played through the iOS device's built-in speaker. Accessory team has suggested to establish SCO connection to route the tones through WM500. But iOS does not provide an external API (like Android's startBluetoothSco) to explicitly force the establishment of an SCO connection for notification tones. Is there any other approach to establish SCO connection in iOS to route notification tones through WM500

When an iOS device is connected to a Bluetooth accessory that utilizes the Hands-Free Profile (HFP), we are encountering an incorrect audio routing behavior specifically for system notification tones. Accessory Connected: The iOS device is successfully connected to a Bluetooth accessory (specifically, a WM500 device) using the HFP profile for voice communication. Voice Audio: Audio streams related to phone calls or voice communication (using the HFP/SCO link) are correctly routed to the WM500. Notification Tones Issue: System notification tones, which are played using the tonetype.systemsounds API, are not being routed to the connected HFP accessory (WM500). Instead, they are incorrectly played through the iOS device's built-in speaker. This causes a poor user experience, as critical application alerts and system notifications are missed when the user is relying on the connected HFP accessory for all audio output.

The same code built in a regular Mac app (with UI) does get paired. The characteristic properties are [.read, .write, .notify, .notifyEncryptionRequired] The characteristic permissions are [.readEncryptionRequired, .writeEncryptionRequired] My service is primary. In the iOS app (central) I try to read the characteristic, but an error is reported: Error code: 5, Description: Authentication is insufficient.

I'm scanning for peripherals, and keep references to multiple CBUUIDs - one for each peripheral. I then start a connection to the peripheral. I never get a callback to say the connection succeeded, failed, or disconnected. I have a Mini-Moreph Bluetooth sniffer. The sniffer shows that the iPhone never tried to connect to any of the peripherals. The iPhone HCI logs show that a create connection request was sent, but a cancel connection request was sent 0.018 seconds later. No feedback was given to my application through CoreBluetooth. I've filed this through Feedback Assistant, but expect nothing will come of the report.

Hi, I'm working on an app that integrates third-party UWB accessories using the Nearby Interaction framework. I want to display real-time data via Live Activities, and ideally, I hope the app can continue ranging/interacting with the accessory even when it's in the background—triggering updates in the Live Activity. Specifically: Can I use Live Activity to keep Nearby Interaction sessions running in the background, as long as the accessory is still nearby and connected? Or do I always need to initiate sessions in the foreground? Are there ways to maintain or trigger new Nearby Interaction sessions entirely in the background, when using third-party UWB accessories? Is there any official guidance regarding permissions, user authorization requirements, or restrictions for background ranging with third-party hardware? Are there recommended strategies or patterns for updating Live Activity widgets with data from Nearby Interaction or UWB accessories while backgrounded? (e.g. Bluetooth triggers, push notifications, background tasks) Any advice, experiences, or official recommendations would be greatly appreciated! I want to ensure my implementation is compliant and offers the best possible user experience. Thanks!

The iOS application is a Central Manager connected to a Bluetooth Low Energy (BLE) accessory that utilizes the Hands-Free Profile (HFP). When the application plays a notification tone (using AVAudioPlayer or System Sounds), the audio is incorrectly routed to the device's internal speaker instead of the active HFP headset. How do we programmatically ensure that these notification tones are automatically and reliably routed to the connected HFP headset

the app crashes about 10 seconds after it goes into the background libsystem_kernel.dylib semaphore_wait_trap 100% 45 dyld start + 7116 [0x1825fa000] 100% 44 xxxx main + 76 (main.m:38) [0x104c14000] 100% 43 UIKitCore UIApplicationMain + 336 [0x18ae57000] 100% 42 UIKitCore -[UIApplication _run] + 792 [0x18ae57000] 100% 41 GraphicsServices GSEventRunModal + 120 [0x224975000] 100% 40 CoreFoundation _CFRunLoopRunSpecificWithOptions + 532 [0x185569000] 100% 39 CoreFoundation __CFRunLoopRun + 820 [0x185569000] 100% 38 CoreFoundation __CFRunLoopDoSources0 + 232 [0x185569000] 100% 37 CoreFoundation __CFRunLoopDoSource0 + 172 [0x185569000] 100% 36 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 [0x185569000] 100% 35 BoardServices BSServiceMainRunLoopSourceHandler + 224 [0x19c8b0000] 100% 34 BoardServices __BSSERVICEMAINRUNLOOPQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 52 [0x19c8b0000] 100% 33 libdispatch.dylib _dispatch_block_invoke_direct + 284 [0x1bcf40000] 100% 32 libdispatch.dylib _dispatch_client_callout + 16 [0x1bcf40000] 100% 31 FrontBoardServices -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 168 [0x1a4d45000] 100% 30 FrontBoardServices __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2 + 96 [0x1a4d45000] 100% 29 FrontBoardServices __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2.cold.1 + 352 [0x1a4d45000] 100% 28 FrontBoardServices -[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:] + 708 [0x1a4d45000] 100% 27 FrontBoardServices -[FBSScene _callOutQueue_maybeCoalesceClientSettingsUpdates:] + 128 [0x1a4d45000] 100% 26 FrontBoardServices __76-[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:]_block_invoke.129 + 380 [0x1a4d45000] 100% 25 UIKitCore -[UIApplicationSceneClientAgent scene:handleEvent:withCompletion:] + 336 [0x18ae57000] 100% 24 UIKitCore -[UIScene scene:didUpdateWithDiff:transitionContext:completion:] + 244 [0x18ae57000] 100% 23 UIKitCore -[UIScene _emitSceneSettingsUpdateResponseForCompletion:afterSceneUpdateWork:] + 208 [0x18ae57000] 100% 22 UIKitCore __64-[UIScene scene:didUpdateWithDiff:transitionContext:completion:]_block_invoke.218 + 616 [0x18ae57000] 100% 21 UIKitCore -[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:] + 316 [0x18ae57000] 100% 20 UIKitCore _UISceneSettingsDiffActionPerformChangesWithTransitionContextAndCompletion + 224 [0x18ae57000] 100% 19 UIKitCore +[BSAnimationSettings(UIKit) tryAnimatingWithSettings:fromCurrentState:actions:completion:] + 736 [0x18ae57000] 100% 18 UIKitCore __186-[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:]_block_invoke + 148 [0x18ae57000] 100% 17 UIKitCore -[_UISceneLifecycleMultiplexer uiScene:transitionedFromState:withTransitionContext:] + 244 [0x18ae57000] 100% 16 UIKitCore -[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:] + 608 [0x18ae57000] 100% 15 UIKitCore -[_UISceneLifecycleMultiplexer _performBlock:withApplicationOfDeactivationReasons:fromReasons:] + 212 [0x18ae57000] 100% 14 UIKitCore __101-[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:]_block_invoke + 252 [0x18ae57000] 100% 13 UIKitCore _UIScenePerformActionsWithLifecycleActionMask + 112 [0x18ae57000] 100% 12 UIKitCore __101-[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:]_block_invoke_2 + 512 [0x18ae57000] 100% 11 UIKitCore -[UIApplication _applicationDidEnterBackground] + 136 [0x18ae57000] 100% 10 UIKitCore +[UIViewController _performWithoutDeferringTransitionsAllowingAnimation:actions:] + 140 [0x18ae57000] 100% 9 UIKitCore __47-[UIApplication _applicationDidEnterBackground]_block_invoke + 256 [0x18ae57000] 100% 8 Foundation -[NSNotificationCenter postNotificationName:object:userInfo:] + 92 [0x182c3d000] 100% 7 CoreFoundation _CFXNotificationPost + 736 [0x185569000] 100% 6 CoreFoundation _CFXRegistrationPost + 436 [0x185569000] 100% 5 CoreFoundation ___CFXRegistrationPost_block_invoke + 92 [0x185569000] 100% 4 CoreFoundation __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 [0x185569000] 100% 3 CoreBluetooth -[CBXpcConnection _sendBarrier] + 188 [0x1c2254000] 100% 2 libdispatch.dylib _dispatch_semaphore_wait_slow + 132 [0x1bcf40000] 100% 1 libdispatch.dylib _dispatch_sema4_wait + 28 [0x1bcf40000] 100% 0 libsystem_kernel.dylib semaphore_wait_trap + 8 [0x22d5b6000]

Hi, we have developed an application that streams data from two BLE peripherals at a rate of 14.5kbps per peripheral. Until now, our devices streamed in near real time with no lag on all Apple devices with Bluetooth 5.0 or greater. Since the release of the iPhone 17 series and the iPad A16, we have reports from users of the data being streamed at significantly lower rates than expected. Any help here would be greatly appreciated as our customers are being affected by this change.

I’m on macOS, and when my test app sends BLE advertisements, the advertising packet includes the local name and UUID. If my data exceeds 31 bytes, according to the official documentation, the local name should be moved to the scan response. However, on macOS the local name gets dropped, while on iOS sending the same packet places the local name in the scan response. During macOS testing, the app is in the foreground, and the OS version is macOS 26. Is this behavior expected, and how can I prevent the local name from being discarded?

I’m on macOS, and when my test app sends BLE advertisements, the advertising packet includes the local name and UUID. If my data exceeds 31 bytes, according to the official documentation, the local name should be moved to the scan response. However, on macOS the local name gets dropped, while on iOS sending the same packet places the local name in the scan response. During macOS testing, the app is in the foreground, and the OS version is macOS 26. Is this behavior expected, and how can I prevent the local name from being discarded?

Hello Apple engineering team, We are encountering a BLE connection issue on iPhone 17 series devices running iOS 26.x, while using CoreBluetooth to connect to our Bluetooth accessory in our app Aroma-Link. The problem does not occur on previous iPhone models or earlier iOS versions. Issue Summary Our BLE device uses a specific chipset batch where the 2M PHY capability is not fully supported. The expected behavior (as observed on iPhone 16 / 15 / older models) is: Connection starts on 1M PHY System attempts to upgrade to 2M PHY If 2M PHY upgrade fails → system should fallback and continue using 1M PHY Connection remains active However, on iPhone 17 series: After the system attempts to switch from 1M to 2M PHY and the upgrade fails The device disconnects immediately No fallback to the original 1M PHY occurs This results in an unintended and user-visible disconnection. Reproduction Steps Use an iPhone 17 series device running iOS 26.x Connect to the target BLE peripheral via CoreBluetooth (centralManager connectPeripheral) The system Bluetooth stack initiates a PHY upgrade from 1M → 2M The peripheral rejects / fails the PHY update The connection is disconnected automatically Observed Result centralManager:didDisconnectPeripheral:error: is triggered immediately after the PHY update fails. Expected Result The connection should remain active on 1M PHY, consistent with behavior on: iPhone 16 / 15 / 14 / etc. Earlier iOS versions Impact This causes: Connection instability specifically on iPhone 17 users Inconsistent BLE behavior across device models Unexpected disconnection despite valid 1M PHY link capability Environment Item Details App Aroma-Link Bluetooth Framework CoreBluetooth Devices Affected iPhone 17 series iOS Versions iOS 26.x Reproducibility 100% BLE Peripheral Chipset Specific batch with known 2M PHY limitation Request Could Apple confirm whether the PHY fallback behavior has changed on the iPhone 17 BLE stack, and whether this is an intended change or a regression? We are happy to provide: iOS sysdiagnose logs HCI sniffer captures Peripheral firmware logs Please advise on the recommended next steps for debugging or mitigation. Thank you.

Hello Apple engineering team, We are encountering a BLE connection issue on iPhone 17 series devices running iOS 26.x, while using CoreBluetooth to connect to our Bluetooth accessory in our app Aroma-Link. The problem does not occur on previous iPhone models or earlier iOS versions. Issue Summary Our BLE device uses a specific chipset batch where the 2M PHY capability is not fully supported. The expected behavior (as observed on iPhone 16 / 15 / older models) is: Connection starts on 1M PHY System attempts to upgrade to 2M PHY If 2M PHY upgrade fails → system should fallback and continue using 1M PHY Connection remains active However, on iPhone 17 series: After the system attempts to switch from 1M to 2M PHY and the upgrade fails The device disconnects immediately No fallback to the original 1M PHY occurs This results in an unintended and user-visible disconnection. Reproduction Steps Use an iPhone 17 series device running iOS 26.x Connect to the target BLE peripheral via CoreBluetooth (centralManager connectPeripheral) The system Bluetooth stack initiates a PHY upgrade from 1M → 2M The peripheral rejects / fails the PHY update The connection is disconnected automatically Observed Result centralManager:didDisconnectPeripheral:error: is triggered immediately after the PHY update fails. Expected Result The connection should remain active on 1M PHY, consistent with behavior on: iPhone 16 / 15 / 14 / etc. Earlier iOS versions Impact This causes: Connection instability specifically on iPhone 17 users Inconsistent BLE behavior across device models Unexpected disconnection despite valid 1M PHY link capability Environment Item Details App Aroma-Link Bluetooth Framework CoreBluetooth Devices Affected iPhone 17 series iOS Versions iOS 26.x Reproducibility 100% BLE Peripheral Chipset Specific batch with known 2M PHY limitation Request Could Apple confirm whether the PHY fallback behavior has changed on the iPhone 17 BLE stack, and whether this is an intended change or a regression? We are happy to provide: iOS sysdiagnose logs HCI sniffer captures Peripheral firmware logs Please advise on the recommended next steps for debugging or mitigation. Thank you.

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.

I'm developing an App that works with BLE connection based devices. The BLE connection process, which connects well to the iPhone 16 without any problems, has not worked at all since the iPhone 17. Even when using the same iOS26 version, iPhone 17 is the only one having problems. Progress is stuck after frame 124 in the entire snoop below. Please check if it is a known problem or if there is a solution. 123 2025-11-04 02:01:39.262000 0.000000 localhost () 7c:c6:b6:91:10:04 () ATT 12 Sent Exchange MTU Response, Server Rx MTU: 232 124 2025-11-04 02:01:39.265000 0.003000 localhost () 7c:c6:b6:91:10:04 () ATT 16 Sent Read By Group Type Request, GATT Primary Service Declaration, Handles: 0x0001..0xffff

TN 3115 states that apps that do not use AccessorySetupKit will loose the ability to launch into the background to service bluetooth in iOS26. Starting in iOS 26 and iPadOS 26, only apps that use AccessorySetupKit to setup Bluetooth accessories will be relaunched. Is there any more information regarding this? Will it affect any app under iOS26 or only those build against the iOS26 SDK? My app (dev build) is still relaunched, even though I'm running iOS26, so I wonder if there are any more conditions checked.

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?

This is not a question but rather a small bit of documentation on how Accessory Setup Kit actually works. I spent a couple days figuring this out so I thought let's share my findings. The example app is very light and the documentation definitely has room for improvement so here are a couple important notes. Findings: If you're running > iOS 18 and add any property to your Info.plist file you're no longer able to scan for devices by using CBCentralManager.scanForPeriphals. This will no longer return discoverable devices. Below iOS 18 these properties in the Info.plist are ignored by the OS and you can safely use the "legacy" method of connecting to bluetooth devices. If you're running > iOS 26 the removeAccessory will show a prompt to the user. If you're running < 26 you can silently remove the accessory and start each session with a clean state. If you create CBCentralManager before you start the ASK session you'll not get the state = PoweredOn. If you have 0 accessories connected to your application CBCentralManager will never enter the state = PoweredOn when you create the CBCentralManager. Pre-ASK this would be the trigger for iOS to ask the user permission. This is no longer necessary with ASK. If you have have 1 or more accessories authorized to your app this will be returned in the session.accessories after the session has started. This is an important indicator to determine app behavior. If you have 1 or more accessories CBCentralManager.scanForPeripherals will ONLY return previously authorized AND discoverable devices. Use this for when you want to connect to a previously authorized device. If you have 1 or more accessories and the CBCentralManager.scanForPeripherals returns nothing you can (safely) assume the user attempts to onboard a new device. So for my application I take the following steps: Check for iOS version, if > iOS 18 start ASK session. Are there previously authorized devices? -- yes: run CBCentralManger.scanForPeripherals -- no: show the picker Did the scan return any devices? -- yes: show UI to select device or connect with first available device in the list -- no: show the picker Feel free to add any of your findings and @Apple please update the documentation!

Hi Core Bluetooth team, I’m seeking official clarification on iOS system-level BLE connection management policy, specifically regarding idle timeouts. Question: When iOS disconnects a BLE peripheral with the error: "The connection has timed out unexpectedly." Is this timeout enforced: Per peripheral (each connection has its own idle timer), or Per app / per Bluetooth radio session (one idle timer for all BLE connections in the app)? In other words: Does a single GATT operation (e.g., a write or notification) on any one peripheral reset the idle timeout for all other BLE connections in the same app? Context (General, No App Code): This is about system behavior, not a bug in any specific app. Applies to foreground and bluetooth-central background mode. No state restoration involved. iOS 17–18, all modern devices. Why This Matters: If per-app, one keep-alive can protect multiple peripherals → simplifies design. If per-peripheral, each connection needs independent activity → higher power use. Reference: Core Bluetooth docs recommend “regular GATT operations” but don’t specify scope. WWDC sessions mention “shared Bluetooth radio” but not timeout granularity. Official Answer Requested: Is the BLE idle timeout per peripheral or per app/radio session in iOS? Thank you for the authoritative guidance.

Hello, I am working on iOS app acting as a central that connects to a peripheral which triggers bonding on connection. The pairing is successful on the first connection and after resetting the peripheral (and forgetting the device in Bluetooth Settings). It fails, however, after this devices is forgotten in the Bluetooth Settings at DHKey check, but the peripheral remains turned on. The peripheral is a linux device using BlueZ. This issue does not happen with Android device. Steps: Connect with the peripheral in the app using Core Bluetooth for the first time. Accept the pairing prompt. Bonding is successful and the peripheral is under MY DEVICES in Bluetooth Settings. Forget the device in Bluetooth Settings. Connect with the peripheral in the app using Core Bluetooth. Pairing prompt pops up repeatedly. Sometimes it pops up once, but the pairing is not successful as the device is not present under MY DEVICES. Connect with the peripheral in the app using Core Bluetooth another time. Pairing prompt still shows app. Restarting the peripheral fixes it and central iOS device is able to pair again. Sharing a screen shot from nRF Sniffer for SMP packets which indicate DHKey check failing. I was not able to attach whole log files because of size, let me know if needed I can share them in a different way somehow. Is there anything different in the flow between pairing for the first time and after forgetting the device?