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!

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?

I am pretty sure iOS 13.4 (beta and later) did support Coded PHY (Long Range). Tested devices are iPhone SE2 and iPhone 11 Pro. However, it seems iOS 14 removed the support of Coded PHY, accidentally or on purpose, I don't know? The same PHY update request returns "1M PHY" in iOS 14, but "Coded PHY" in iOS 13 (13.4 beta and later). Anyone knows why? Samson

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.

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)">.

Hello! I'm working on a mobile app that communicates with a peripheral via Bluetooth with security level 2 in a customised way, as there are also other communication protocols used. We use a bluetooth service with a specific UUID that has a write characteristic for sending data to the device and a notify characteristic for receiving data from the device. After connecting for the first time, a pairing prompt appears after successful connection and subscribing to notifications. When all is set, that is notifications are enabled, a handshake is performed and a communication session is established. There can be only one session for a bluetooth connection. So I have two questions: Regarding the pairing, is there any way that I can know the result of the pairing, so that I could start the handshake after it is accepted? What could be the best approach here? Asking because I noticed some instability on first connection (peripheral ignoring handshake). After disconnecting using Core Bluetooth, the system maintains the connection for some time before actually disconnecting. When opening the app shortly after killing the previous instance, it gets connected very quickly as it reuses the existing connection. The problem is, however, that the device wouldn't accept the new handshake and it is pretty much impossible to reuse previous session. In our use case we need a new BLE connection for each session. Is there any way I could forcibly disconnect from the device or enforce a new connection (not a reused one)? What might be the best approach here? The way I handle it now is by using retrieveConnectedPeripherals and if the device is found to be connected, I use scanning. If the device is advertising then we know it's not connected. Other than that we could also poll retrieveConnectedPeripherals and wait. But obviously it is not optimal, as the user has to wait longer than ususal. Other than that retrievePeripherals is used for getting the peripheral, if the app once found it during scanning. I saw this post describing similar issue, is it the only solution to implement API for disconnecting on the peripheral side?

Application has specified the bluetooth-central background mode. Peripheral Device(BLE) is connected to the iPhone. Application will initiate a request 'retrieveConnectedPeripheralsWithServices' along with list of services to scan for. Application will receive a list of peripherals connected to the system whose service UUID's match. From the list of peripherals, application will initiate a request 'connectPeripheral' with the interested peripheral along with the option set to 'CBConnectPeripheralOptionEnableAutoReconnect'. This option is available from iOS 17+. CBConnectPeripheralOptionEnableAutoReconnect - This option will help in reconnect back to peripheral when peripheral becomes available. (Turn OFF and Turn ON) How do we achieve the same thing in earlier IOS version

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

FB18383742 Setup 🛠️ Xcode 16.4 (16F6) 📱 iPhone 13 mini (iOS 18.0.1) ⌚️ Apple Watch Series 10 (watchOS 11.3.1) Observations As AccessorySetupKit does not request "Core Bluetooth permissions", when a watchOS companion app is installed after having installed the iOS app, the toggle in the watch settings for Privacy & Security > Bluetooth is turned off and disabled After removing the iPhone associated with the Apple Watch, Bluetooth works as expected in the watchOS app Upon reinstalling the iOS app, there's a toggle for Bluetooth in the iOS ASK app's settings and the ASK picker cannot be presented 🤨 From ASK Documentation: AccessorySetupKit is available for iOS and iPadOS. The accessory’s Bluetooth permission doesn’t sync to a companion watchOS app. But this doesn't address not being able to use Core Bluetooth in a watch companion app at all 🥲 Reproducing the bug Install the iOS + watchOS apps Launch iOS app, tap "start scan", observe devices can be discovered (project is set up to find heart rate monitors) Launch watchOS, tap allow on Bluetooth permission pop-up watchOS app crashes 💥 Meanwhile, in the iOS app, there should be a log entry for 💗 CBCentralManager state: poweredOff and the ASK picker is no longer able to discover any devices The state of the device permissions: iOS app has no paired accessories or Bluetooth permission watchOS app's Bluetooth permission shown as turned off & disabled Remove the iOS app Relaunch the watchOS app Notice the CBCentralManager state is unauthorized Remove and reinstall the watchOS app Tap allow on Bluetooth permission pop-up watchOS app does not crash and CBCentralManager state is poweredOn The state of the watch permissions: Bluetooth is turned on & the toggle is not disabled Note that at this time the iOS app is not installed, there is no way to remove Bluetooth permission for the watch app. Reinstall + launch the iOS app Notice a warning in the log: [##### WARNING #####] App has companion watch app that maybe affected if using CoreBluetooth framework. Please read developer documentation for AccessorySetupKit. Notice a log entry for 💗 CBCentralManager state: poweredOn before tapping start scan Tap start scan and observe another log entry: Failed to show picker due to: The operation couldn’t be completed. (ASErrorDomain error 550.) ASErrorDomain 550: The picker can't be used because the app is in the background. Is this the expected error? 🤔 The state of the iOS permissions: The app's settings show a Bluetooth toggle normally associated with Core Bluetooth, but the app never showed a Core Bluetooth pop-up The iOS ASK app now has Core Bluetooth permission 😵‍💫 Following up with Apple This is a known bug that should be fixed in watchOS 26 when Bluetooth permissions for watch apps can be set independently of the iOS app. I've yet to test it with watchOS 26. See repo for the same post with screenshots of the settings and demo code reproducing the bug: https://github.com/superturboryan/AccessorySetupKit-CoreBluetooth-watchOS-Demo

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?

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?

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?

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.

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.

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