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!

My team has an app that uses BTLE heavily, and has been doing so successfully, including no issues continuing to receive data in the background and updating things in the app (for recording workouts). We have a BTLE write queue that only tries to write when the CBPeripheral.canSendWriteWithoutResponse property is true, or when we get the notification from the system in peripheralIsReady(toSendWriteWithoutResponse:). This is used as a means to rate limit data transfer, as we transfer files, as well as require that packets always arrive in the correct order due to blob encoding. However, we had a new requirement come in to periodically write data out to a connected peripheral. I noticed that as soon as the app was in the background, despite other delegate callbacks coming in, like didRecieveUpdatedValue:, neither the property canSendWriteWithoutResponse nor the delegate callback were called any longer. This meant our write queue didn't think it had permission to write, and packets would just stack up. The failure to deliver these updates didn't occur immediately after backgrounding, but did within 2-5s of backgrounding. If, when in the background, I ignore the changing of that property, and instead just write the data to the peripheral, it works! Can anyone explain why, despite other CBPeripheral callbacks happening when in the background, this one does not?

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

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?

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

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?

After the macOS Sequoia update, my app seems to have an issue with Bluetooth communication between macOS and iOS that uses CoreBluetooth for Central-Peripheral communication. Setup: The iPhone (in my case: iPhone 14 Pro with iOS 18.0 (22A3354)) acts as the Central, and the Mac (in my case: 14" MacBook Pro 2023 with macOS 15.0 (24A335)) as the Peripheral. I’ve implemented a mechanism where the Central (iPhone) sends a message to the Peripheral (Mac) every 15 seconds to keep the connection alive (Because it needs to wait for notify characteristic updates). I never noticed this kind of issue before, but with macOS Sequoia I get it permanently. Issue: The connection drops unexpectedly after a period of time (sometimes 20 seconds, sometimes a few minutes) with CBErrorDomain - code 6: The connection has timed out unexpectedly. Sample Code: Peripheral (Mac): ContentView (Peripheral).txt ContentViewModel (Peripheral).txt Central (iPhone): ContentView (Central).txt ContentViewModel (Central).txt Reproduce: I attached sample code including the Central-Sample (for iPhone) and Peripheral-Sample (for Mac). Just run the Peripheral-Sample (after granting Bluetooth permissions). Then run the Central-Sample and select the Mac device in the list After selecting it should connect, discover the service & characteristic and should start writing messages to it. After some time the func centralManager(_ central: CBCentralManager, didDisconnectPeripheral peripheral: CBPeripheral, error: (any Error)?) {should get called with timed out unexpectedly error. Could anyone please look into this issue and advise on whether there’s a known bug or any workaround? Any guidance would be greatly appreciated, as this impacts the stability of Bluetooth communication between the devices. Thanks in advance. Logs: I also ran the console.app during this issue which got these errors (if this is helpful): console_logs.txt

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'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?

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

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?

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

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?