mac/ios acts as a BLE client. After successfully establishing a BLE connection, it sends large amounts of data to the peer device. After sending data for a period of time, the system does not return peripheralIsReadyToSendWriteWithoutResponse for a long time, causing the data transmission to stall.

I'm experiencing intermittent failures when executing APDU (Application Protocol Data Unit) commands through Core Bluetooth to communicate with external secure elements. The communication flow involves establishing a BLE connection, discovering services and characteristics, and then sending structured APDU commands for card management operations. While the initial connection and characteristic discovery work reliably, I'm encountering inconsistent behavior during APDU command execution where commands either timeout, return unexpected response codes, or fail to complete the expected transaction sequences. The issue appears to be more prevalent when sending multiple APDU commands in rapid succession or when the commands involve cryptographic operations. I've implemented proper error handling and retry mechanisms, but the failures seem to occur at the Core Bluetooth level rather than in my application logic. The peripheral device responds correctly to the same commands when tested with other platforms, suggesting the issue might be related to iOS-specific BLE behavior or timing constraints. I'm using standard Core Bluetooth APIs (CBPeripheral, CBCharacteristic) with proper delegate implementations and have verified that the peripheral remains connected throughout the operation. Has anyone encountered similar issues with APDU command execution over BLE on iOS, and are there any known workarounds or best practices for ensuring reliable command delivery and response handling?

I'm developing an application using the accessory setup kit (BLE) on iOS 18+. An important aspect of the connection process is being able to find and choose the correct device. I noticed on iOS 18.2 that I was able to both scroll through the discovered accessories as well as view the advertised name. However, after upgrading to 18.7.2, only a single device is viewable and the advertised name is no longer available. Is there a trigger for this feature that I need to enable or was this "multiple discovery" feature removed? If so, why?

I am looking to extend the range for a device and the only option from a Bluetooth perspective is Coded PHY but I have not heard of any intent to support it from Apple. Does Apple intend to support Coded PHY and if so what is the roadmap?

Hi All, I'm working on an app that needs to connect to BLE device and on defined schedules download data from the device. the amount of data is segnificant and might take around a minute to download. we tought about utilizing both state restoration and preservation for app waking and scheduling (triggered by the ble peripheral) and BGTaskScheduler to schedule a task that will handle a long running task to manage the full data download. now, will this solution in general valid? isnt it a "hack" that goes around the 10s limit that state restoration enforces? i know there are limitations for BGTask (like when it runs, it might be terminated by the system etc) but considering that, can we proceed with this approach without breaching apple guidelines? thank you in advance!

My phone turns or gets connected to Beats, Aipods max 2, and sometimes the Marshall Bluetooth device but it keeps triggering the automation for “When Connected To Bluetooth” - My Car tried deleting and recreating the automation and it’s still buggy.

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?

When our Bluetooth device is scanned and a connection is initiated through the app on the iPhone 17, the air log shows that the iPhone sends an LL_LENGTH_REQ to execute the Data Length Update Procedure. However, our peripheral does not support the Bluetooth LE Data Length Extension, so it responds with an LL_UNKNOWN_RSP PDU with the UnknownType field set to LL_LENGTH_REQ. After receiving the LL_UNKNOWN_RSP, the iPhone 17 does not proceed with the subsequent Bluetooth LE service discovery process. The connection is maintained until the peripheral actively disconnects. Once the peripheral disconnects and continues broadcasting Bluetooth signals, the iPhone 17 repeatedly tries to connect to the peripheral and executes the aforementioned process, even if the app has been terminated. According to the Bluetooth 4.2 core specification ([Vol. 6] Part B, Section 5.1.9), which can be found here: https://www.bluetooth.com/specifications/specs/core-specification-amended-4-2/, the iPhone should accept the LL_UNKNOWN_RSP and terminate the Data Length Update Procedure after receiving it, proceeding with the subsequent operations using the default minimum parameters. Phenomenon: When the app calls the - (void)connectPeripheral:(CBPeripheral *)peripheral options:(nullable NSDictionary<NSString *, id> *)options method, the connection result callback is never received. After a period of approximately 10 seconds, it fails with a callback, displaying the message: central did fail to connect to peripheral: <TY : 45E4A697-31AE-9B5A-1C38-53D7CA624D8C, Error Domain=CoreBLEErrorDomain Code=400 "(null)">.

We are working with Bluetooth peripherals using CoreBluetooth, and I've noticed that the CBPeripheral.name property seems to be cached. Has anyone else encountered this behavior? Is this caching expected behavior in CoreBluetooth? Is there a recommended way to force refresh or invalidate the cached name? Most importantly: Is there a reliable method to get the most accurate and up-to-date name of a peripheral?

Hello, I am developing with the Nearby Interaction framework using third-party UWB accessories (Murata SR040/SR150). I observed a difference between U1-based and U2-based iPhones: iPhone 12 Pro (U1 chip) NINearbyObject.direction returns valid 3D vector (x, y, z). Distance and direction both work as expected. iPhone 15 Pro and iPhone 16 Pro (U2 chip) NINearbyObject.direction is always nil. Only distance is returned (around 0.35–0.40 m in my test). Effectively behaves as "distance-only mode". Environment: Hardware: iPhone 12 Pro, iPhone 15 Pro iOS version: 18.5 Accessory: Murata UWB SR040 / SR150 App: Using NINearbyAccessoryConfiguration with BLE-based discovery Info.plist includes NSNearbyInteractionUsageDescription Camera assistance was tested both ON and OFF Expectation: I expected the U2 chip to behave consistently with U1, i.e. provide direction vectors when possible. Instead, on iPhone 15 Pro, direction is always unavailable (nil) while distance is returned correctly. Questions: Is this an intentional limitation for U2 chip + third-party accessories? Is there a new requirement (e.g. certification, firmware update, capability flags) to enable direction on U2 devices? Could this be related to NIDeviceCapability or the new Extended Distance Measurement (EDM) mode in U2? Thanks in advance for any clarification.

[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 We found that our app had a lot of crashes on iOS 26. The crash stack showed [CBXpcConnection _sendBarrier]. The following is the crash log: Thread 0 name: com.apple.main-thread (cpu_usage: 0.00%) 1 libsystem_kernel.dylib _semaphore_wait_trap (in libsystem_kernel.dylib) 2 libdispatch.dylib __dispatch_sema4_wait (in libdispatch.dylib) 3 libdispatch.dylib __dispatch_semaphore_wait_slow (in libdispatch.dylib) 4 CoreBluetooth -[CBXpcConnection _sendBarrier] (in CoreBluetooth) 5 CoreFoundation ___CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ (in CoreFoundation) 6 CoreFoundation ____CFXRegistrationPost_block_invoke (in CoreFoundation) 7 CoreFoundation __CFXRegistrationPost (in CoreFoundation) 8 CoreFoundation __CFXNotificationPost (in CoreFoundation) 9 Foundation -[NSNotificationCenter postNotificationName:object:userInfo:] (in Foundation) 10 UIKitCore ___47-[UIApplication _applicationDidEnterBackground]_block_invoke (in UIKitCore) 11 UIKitCore +[UIViewController _performWithoutDeferringTransitionsAllowingAnimation:actions:] (in UIKitCore) 12 UIKitCore -[UIApplication _applicationDidEnterBackground] (in UIKitCore) 13 UIKitCore ___101-[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:]_block_invoke_2 (in UIKitCore) 14 UIKitCore __UIScenePerformActionsWithLifecycleActionMask (in UIKitCore) 15 UIKitCore ___101-[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:]_block_invoke (in UIKitCore) 16 UIKitCore -[_UISceneLifecycleMultiplexer _performBlock:withApplicationOfDeactivationReasons:fromReasons:] (in UIKitCore) 17 UIKitCore -[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:] (in UIKitCore) 18 UIKitCore -[_UISceneLifecycleMultiplexer uiScene:transitionedFromState:withTransitionContext:] (in UIKitCore) 19 UIKitCore ___186-[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:]_block_invoke (in UIKitCore) 20 UIKitCore +[BSAnimationSettings(UIKit) tryAnimatingWithSettings:fromCurrentState:actions:completion:] (in UIKitCore) 21 UIKitCore __UISceneSettingsDiffActionPerformChangesWithTransitionContextAndCompletion (in UIKitCore) 22 UIKitCore -[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:] (in UIKitCore) 23 UIKitCore __64-[UIScene scene:didUpdateWithDiff:transitionContext:completion:]_block_invoke.218 (in UIKitCore) 24 UIKitCore -[UIScene _emitSceneSettingsUpdateResponseForCompletion:afterSceneUpdateWork:] (in UIKitCore) 25 UIKitCore -[UIScene scene:didUpdateWithDiff:transitionContext:completion:] (in UIKitCore) 26 UIKitCore -[UIApplicationSceneClientAgent scene:handleEvent:withCompletion:] (in UIKitCore) 27 FrontBoardServices __76-[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:]_block_invoke.129 (in FrontBoardServices) 28 FrontBoardServices -[FBSScene _callOutQueue_maybeCoalesceClientSettingsUpdates:] (in FrontBoardServices) 29 FrontBoardServices -[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:] (in FrontBoardServices) 30 FrontBoardServices __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2.cold.1 (in FrontBoardServices) 31 FrontBoardServices ___94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2 (in FrontBoardServices) 32 FrontBoardServices -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] (in FrontBoardServices) 33 libdispatch.dylib __dispatch_client_callout (in libdispatch.dylib) 34 libdispatch.dylib __dispatch_block_invoke_direct (in libdispatch.dylib) 35 BoardServices ___BSSERVICEMAINRUNLOOPQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ (in BoardServices) 36 BoardServices _BSServiceMainRunLoopSourceHandler (in BoardServices) 37 CoreFoundation ___CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (in CoreFoundation) 38 CoreFoundation ___CFRunLoopDoSource0 (in CoreFoundation) 39 CoreFoundation ___CFRunLoopDoSources0 (in CoreFoundation) 40 CoreFoundation ___CFRunLoopRun (in CoreFoundation) 41 CoreFoundation __CFRunLoopRunSpecificWithOptions (in CoreFoundation) 42 GraphicsServices _GSEventRunModal (in GraphicsServices) 43 UIKitCore -[UIApplication _run] (in UIKitCore) 44 UIKitCore _UIApplicationMain (in UIKitCore) Thanks

Hello. Is there a solution to the issue where Core Bluetooth does not run in the background on the iPhone17? https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html The bluetooth-central Background Execution Mode When an app that implements the central role includes the UIBackgroundModes key with the bluetooth-central value in its Info.plist file, the Core Bluetooth framework allows your app to run in the background to perform certain Bluetooth-related tasks. While your app is in the background you can still discover and connect to peripherals, and explore and interact with peripheral data. In addition, the system wakes up your app when any of the CBCentralManagerDelegate or CBPeripheralDelegate delegate methods are invoked, allowing your app to handle important central role events, such as when a connection is established or torn down, when a peripheral sends updated characteristic values, and when a central manager’s state changes. Although you can perform many Bluetooth-related tasks while your app is in the background, keep in mind that scanning for peripherals while your app is in the background operates differently than when your app is in the foreground. In particular, when your app is scanning for device while in the background: The CBCentralManagerScanOptionAllowDuplicatesKey scan option key is ignored, and multiple discoveries of an advertising peripheral are coalesced into a single discovery event. If all apps that are scanning for peripherals are in the background, the interval at which your central device scans for advertising packets increases. As a result, it may take longer to discover an advertising peripheral. These changes help minimize radio usage and improve the battery life on your iOS device.

Our app scans Bluetooth in the background. However, the iPhone 17 device does not scan in the background. ios 26 Is there anything I need to do? The setting values are as follows. device connection interval min : 60 connection interval max : 75 slave latency : 0 supervision timeout : 4000 advertising interval : 20

Our app scans Bluetooth in the background. However, the iPhone 17 device does not scan in the background. ios 26 Is there anything I need to do? device1 connection interval min : 60 connection interval max : 75 slave latency : 0 supervision timeout : 4000 advertising interval : 20

Our app scans Bluetooth in the background. However, the iPhone 17 device does not scan in the background. ios 26 Is there anything I need to do?

Recently, I've noticed that background Bluetooth scanning stops when I move an app to the background on an iPhone 17 device with Bluetooth 6. I'm curious about a solution. Background Bluetooth scanning doesn't stop on devices older than iOS 26, or on devices that were updated from an iPhone 17 or earlier to iOS 26.

Recently, I've noticed that background Bluetooth scanning stops when I move an app to the background on an iPhone 17 device with Bluetooth 6. I'm curious about a solution. Background Bluetooth scanning doesn't stop on devices older than iOS 26, or on devices that were updated from an iPhone 17 or earlier to iOS 26.

PLATFORM AND VERSION Model - iPhone 13 Pro Max (Potentially for other models also) OS - iOS 26 DESCRIPTION OF PROBLEM : BLE discoverability (advertising) is not working on iOS 26 but works reliably on older iOS versions. Details: Our app acts as a Bluetooth peripheral. When advertising, the app only adds CBAdvertisementDataLocalNameKey in advertisement data. Format of local name - "NTDI:103202400001" We have observed that in iOS 26, the local name is getting truncated. This breaks the parsing logic in our IOT device central code, which expects the full local name to be present. We have also observed that some extra data is getting added to the advertisement data by the OS. As of now, updating the IOT device logic for parsing is not possible. STEPS TO REPRODUCE Create an instance of CBPeripheralManager. Start advertising with a local name with the format "NTDI:103202400001" Capture the advertisement data using a Bluetooth sniffer tool. Observe that the local name is getting truncated Legacy ADV_IND as received by IoT device (truncated name): HCI Event: LE Meta Event (0x3e) plen 27 LE Advertising Report (0x02) Event type: ADV_IND (0x00) Data length: 15 Flags: 0x1a TX power: 12 dBm 12 09 4e 54 44 49 3a 31 30 ..NTDI:10 RSSI: -47 dBm Only partial Local Name (“NTDI:10…”) is present in this primary PDU. Is it possible to avoid the extra data introduced by iOS or avoid local name truncation?