Hi, I am trying to understand if I am able to get bluetooth scanning for advertisements (no service UUID) when the app is moved into the background and the screen goes to sleep. I am using swift on ios26.2 with a bluetooth class that uses the standard centralManager.scanForPeripherals to listen for particular Beacons. Testing on a real iPhone 15 this works fine whilst in the foreground, and also when on the lock screen. I am trying to get this to continue working in the background when the black screen sleep mode is on. I have the bluetooth 'Uses Bluetooth LE accessories' in the background modes (as well as Audio, Airplay..) and the necessary Bluetooth peripheral usage description, bluetooth always usage descriptions in info.plist. I launch a LiveActivity whilst the app is in the foreground and bluetooth has started scanning. From my understanding of core bluetooth with ios26 the LiveActivity should allow the scan to continue (without service UUIds and aggressive throttling) whilst the app is in the background. Well this seems to work fine.. if I press the side button the phone goes to the Lock Screen, and whilst on the Lock Screen the bluetooth is scanning fine and receiving beacon data. Similarly if the app is sent to the background behind a different foreground app it also works. As soon as the screen goes to sleep however (after only a few seconds of inactivity on the Lock Screen) then all bluetooth scanning stops. If I click back on the screen and bring the Lock Screen up, then scanning resumes again. Now is it possible to continue the scanning whilst the phone is in sleep mode (i.e. black screen)? Are there any additional acceptable steps to make the bluetooth scanning continue when the screen has gone to sleep. Or is it part of the design with core bluetooth that the 'continues in the background' feature only applies to the lock screen and when other active apps are brought to the foreground on an open phone. I want to understand the limitations of what can be achieved so I am not chasing unachievable objectives. Thanks

I’ve built an app that connects via Bluetooth to a device. The device sends up, down, left and right commands. I want to build an SDK for other third party developers to use so that whenever a third party app with the SDK opens, if we press a button on the device, my app which captures the button press should be able to forward the event to the third party app. I want to achieve this with the lowest latency possible so that I can enable a variety of use cases like simple games and interactions within other apps. What would be the best way for me to achieve this as part of my SDK and my app?

Is this even possible? Instead of any pairing dialog appearing, my central code get the "Authentication is insufficient" error when reading the characteristic. My peripheral (in the macOS app) code uses the .notifyEncryptionRequired property and uses .readEncryptionRequired and .writeEncryptionRequired permissions. No descriptors are set, but I think they get added automatically since this characteristic notifies. 2900 and 2902 descriptors are set by the peripheral/CoreBluetooth. If the Mac and iPhone are using the same Apple ID does that affect pairing?

I am implementing BLE scanning and connection using CoreBluetooth in a Flutter application with native iOS Swift code. BLE scanning and connection work correctly in the foreground and for a short time after the app is sent to the background. However, after some time in the background, BLE scanning stops and the device is no longer discovered. The app appears to be suspended by iOS. Key Observation: When location services are actively in use (navigation arrow visible in the iOS status bar), BLE scanning and reconnection work reliably in the background. When location services are not actively running, BLE scanning stops in the background even though the app has “Always Allow” location permission. Expected Result BLE scanning and connection should continue to function in the background using the Bluetooth LE background mode, without relying on active location updates. Actual Result BLE scanning starts successfully App enters background After some time, scanning stops Device is no longer discovered BLE works again only if location services are actively running BLE Connection Behavior One-time scan connects successfully to a BLE medical device App is sent to background Existing connection does not disconnect However, new scans or reconnections fail once the app is suspended Relevant Native iOS Code (AppDelegate) import Flutter import UIKit import CoreBluetooth @main @objc class AppDelegate: FlutterAppDelegate { private var backgroundTaskID: UIBackgroundTaskIdentifier = .invalid override func application( _ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? ) -> Bool { GeneratedPluginRegistrant.register(with: self) if let identifiers = launchOptions?[UIApplication.LaunchOptionsKey.bluetoothCentrals] as? [String] { print("App relaunched for BLE state restoration: \(identifiers)") } NotificationCenter.default.addObserver( self, selector: #selector(appDidEnterBackground), name: UIApplication.didEnterBackgroundNotification, object: nil ) return super.application(application, didFinishLaunchingWithOptions: launchOptions) } @objc private func appDidEnterBackground() { backgroundTaskID = UIApplication.shared.beginBackgroundTask { self.endBackgroundTask() } } private func endBackgroundTask() { if backgroundTaskID != .invalid { UIApplication.shared.endBackgroundTask(backgroundTaskID) backgroundTaskID = .invalid } } } Questions for DTS: Is it expected behavior that CoreBluetooth background scanning effectively stops once the app is suspended, even when the Bluetooth LE background mode is enabled? Why does BLE background scanning appear to work reliably only when location services are actively running? Is iOS internally associating BLE background execution with active location updates? For continuous BLE reconnection (medical device use case), is the recommended approach to rely solely on CoreBluetooth state restoration instead of continuous background scanning? Is it considered best practice to avoid long-running BLE scans in the background and instead wait for system-delivered BLE events? Additional Notes Issue is reproducible on real devices Not using private APIs or unsupported background execution methods Objective is to follow Apple-recommended, App Store–compliant behavior

For our research study, it is essential that the app can advertise BLE packets even when the app is no longer in the foreground (for example, when it is in the app switcher / recents state). Is it supported to advertise BLE packets while the app is in the background or recents state? If so, what are the specific requirements or limitations we should be aware of (background modes, payload size, timing, etc.)? Are there any constraints that would prevent consistent BLE advertising for research use cases?

Hello Apple Forums, We are developing an iOS application that connects to a custom BLE accessory and sends control commands to it. Our system architecture is as follows: A separate hardware device collects data and sends it to our backend server via Wi-Fi. The backend evaluates state changes and determines when the BLE accessory should update its display. The iOS app acts purely as a BLE command executor for this accessory. Our goal is to: Maintain a BLE connection with the accessory while the app is in the background. Receive state-change events from our backend server. Upon receiving such events, send a BLE command to the accessory to update its state. We understand that iOS does not allow arbitrary background execution. We would like to confirm whether there is any supported mechanism, entitlement, or program that allows: Long-running background execution for BLE control, or Server-originated events (other than APNs) to trigger background BLE actions. If this is not supported, we would appreciate confirmation that APNs (silent push) is the only supported way to trigger such background BLE actions, or guidance on any recommended alternative architectures. Thank you for your guidance.

I built an iOS app and debugged it using my iPhone 11. It works fine. My app uses Bluetooth because the physical data logger reads data via Bluetooth. I published it to the Apple store. After installing it on the iPhone 13 pro. The app works, but the device is not selected.

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

I'm developing an App, a function is through the bluetooth firmware upgrade. there is a problem now. when I send data via bluetooth, App into the background, the data sent to immediately stop, peripheralIsReadyToSendWriteWithoutResponse will not be invoked, At the same time canSendWriteWithoutResponse always returns false. When I open the App again, peripheralIsReadyToSendWriteWithoutResponse still will not be invoked, canSendWriteWithoutResponse or returns false. I have set Acts as a Bluetooth LE accessory and Uses Bluetooth LE accessories. Is there a good way to send data to the device when my App goes into the background?

Hello, Is there a 2-device limit for CoreBluetooth on visionOS 2.1? My app connects to 4 BLE peripherals on iOS but fails at the 3rd device on Vision Pro. The 3rd call to centralManager.connect() is successful and the peripheral enters .connecting state, but didConnect never fires and it stays in .connecting forever. No errors reported. First 2 devices work perfectly. Same code on iOS connects all 4. Has anyone else had this problem? Is there any documentation I can refer to that states something like this? Environment: visionOS 2.1, CoreBluetooth, Apple Vision Pro. My BLE Peripherals are running on nRF52840.

When using CBPeripheralManager in the peripheral role on iPhone 17 series devices (iPhone 17 Air, iPhone 17 Pro) running iOS 26.1 and above, the delegate method peripheralManager:central:didSubscribeToCharacteristic: is never called when a third-party BLE central device attempts to connect and subscribe to a characteristic. This functionality works correctly on all previous iPhone models and iOS versions. (This worked previously for the same iPhone 17 Air/Pro when running iOS 26.0.1.)

Hello guys, I have been trying to advertise in the background but I can’t seem to make it work. In my case, I want if a device is acting as a peripheral and the app goes to the background it still can be discoverable and be able to write/read to/from it by the central. I have added the background mode “Acts as a Bluetooth accessory”. When will willRestoreState be called? What should I do in willRestoreState? Will it always be discoverable or have some limitations? Should I stop advertising at any point? How should I clean up after the view is dismissed? Must the peripheral manager be initialized in the AppDelegate? and if so, will it always be advertising even if I don't want it to? What are the battery concerns? Also, I have encountered an issue that my iPhone device can discover an Android device but not the opposite. What could be the problem of this? Thank you. Best regards

We are observing some unexpected behavior in our app when using ASK. Our app is able to successfully discover and set up an accessory via ASK. After the setup completes, the connection to the accessory is managed through CBCentralManager and works as expected. However, when we attempt to discover another accessory afterward, the picker is shown and indicates that accessory discovery is in progress. After approximately 10 seconds, the CBCentralManager delegate reports the Bluetooth state as poweredOff. Once this happens, the state never transitions back to poweredOn. At this point, the only way to reconnect to the device or continue discovery is to relaunch the app. We are wondering if anyone else has encountered similar behavior, or if this is a known or documented limitation/behavior when using ASK in combination with CBCentralManager.

Hi! We have created an app that communicates with devices over BLE, and it is currently out in Testflight. It works as expected for almost everyone, but for some users we get a strange behaviour. We start by scanning for devices with scanForPeripherals(withServices:options:), then connect, and finally initiate pairing by subscribing and writing to a pair of characteristics, which both require encryption. The issue is that for these users, the following code: func peripheral( _ peripheral: CBPeripheral, didDiscoverCharacteristicsFor service: CBService, error: Error? ) { guard error == nil else { LogManager.shared.log( "❌ Error discovering characteristics: \(error!)" ) return } for characteristic in service.characteristics ?? [] { if characteristic.uuid == controlPointUUID { controlPointCharacteristic = characteristic LogManager.shared.debugLog( "Control Point characteristic found." ) } else if characteristic.uuid == statusUUID { statusCharacteristic = characteristic LogManager.shared.debugLog("Notify characteristic found.") } } if statusCharacteristic != nil { LogManager.shared.debugLog("Call Set notify.") peripheral.setNotifyValue(true, for: statusCharacteristic!) } } func peripheral( _ peripheral: CBPeripheral, didUpdateNotificationStateFor characteristic: CBCharacteristic, error: Error? ) { if error != nil { LogManager.shared.log( "❌ Failed to subscribe to \(characteristic.uuid): \(error.debugDescription)" ) produces this error: > > [22:31:34.632] ❌ Failed to subscribe to F1D0FFF2-DEAA-ECEE-B42F-C9BA7ED623BB: Optional(Error Domain=CBATTErrorDomain Code=15 "Encryption is insufficient." UserInfo={NSLocalizedDescription=Encryption is insufficient.}) So in essence, we can't perform pairing and enable encryption, because we have insufficient encryption. I know that the system caches some key material after pairing. When I do "Forget device" and then pair again, I don't need to put my device in pairing mode for the pairing pin to appear, which is not the case for devices that have not been paired before. Given that I can't reproduce the problem locally, it's hard to debug using the console. What I've been trying to do is figure out how to reset Bluetooth, which should hopefully remove old keys and whatever else might be there. The top hit when searching for 'clear corebluetooth cache macos' is on stackexchange, and writes: Turn off Bluetooth Delete com.apple.Bluetooth.plist from /Library/Preferences Delete files named com.apple.Bluetooth.somehexuuidstuff.plist from ~/Library/Preferences/ByHost (note that this is the user preference folder, not the system one) Turn on Bluetooth The answer is from December 2013, so it's not surpising that things don't work out of the box, but anyways: My ByHost folder does not contain any plist files with Bluetooth in them, and deleting the one in /Library/Preferences did not do anything, and judging from the content, it does not contain anything valuable. I have tried "sudo grep -r 'Bluetooth' ." in both /Library/Preferences/ and ~/Library/Preferences/ and looked at the resulting hits, but I can't seem to find anything meaningful. As a sidenote, does anyone know what is going on with Apple's entitlement service? We applied for an entitlement in August and have yet to receive a response.

I need to design an iOS app but have no experience (I only know embedded C). The app should be fairly simple, it just needs to create a binary file based on options (enable/disable) and then send that binary file using BLE. I already have a Python script which runs on Windows/Mac that generates the binary file and sends the binary file over BLE. But now I need to get this working on an iOS app. I can connect to the bluetooth receiver (BT401) using the Lightblue app to send and receive commands via UART pass through. A similar app already exists (VOG-Altimeter) where altitudes are enabled/disabled.... I need to do the same sort of thing and once the settings have been made, generate the binary file and send it via BLE. So the steps are: Create a bluetooth connection (to the BT401) like the LIghtblue app does Create a binary file based on the settings like I currently do with the Python script Send the binary file via BLE connection (to the BT401) like I currently do with the Python script. I already have this working with the Python script, but don't know how to develop an app to do the same. Can anyone help or give me pointers on how to proceed ? I tried ChatGPT but it couldn't even get the BLE connection to work.

I have an app that uses BLE to connect to access doors. Since iOS 26, when it hasn't connected to any doors for a while, it deactivates, whereas in older versions of iOS it continues to work all day without stopping. Has anyone else experienced this? I've found problems with people who have had the same issue since upgrading to the latest version of iOS 26. Is there a known issue with BLE in iOS 26? I haven't found any official information. thnks

My main goal is to maximize BLE range at the moment, though eventually I would like to allow for greater throughput when updating firmware over the air as well. I understand that Coded PHY is not on the roadmap based on the support ticket I previously entered, but is there any way to force 1M PHY. Even when I request it, I get a phy renegotiation (update) of 2 PHY.

We are observing a reproducible issue on some (not all) iPad models equipped with A16, where BLE streaming from multiple peripherals at ≥33–40 Hz results in uneven packet distribution, burst delivery, and application-level lag. The same application, peripherals, firmware, iOS version, and physical environment do not exhibit this behaviour on A14-based iPads (iPad 10). Affected Hardware: • iPad 11" with A16 • iOS versions: identical across tested devices • Issue affects some devices of the same model, not all Internal field data • ~25 affected • ~5 unaffected • Customers actively prefer iPad 10 (A14) due to stability When two or more BLE peripherals stream data concurrently at frequencies ≥33–40 Hz, affected iPads exhibit: • Uneven packet arrival timing • Burst delivery instead of uniform intervals • Increasing latency over time • Observable application-level lag This does not present as simple packet loss. Instead, packets arrive in clusters, breaking real-time assumptions. At ≤30–33 Hz, the issue does not reproduce. We tested: • One affected iPad 11 • One unaffected iPad 11 • Same iOS version • Same app build • Same peripherals • Same firmware • Same physical location • Same Wi-Fi state Only the affected device reproduces the issue. This rules out: • App logic • Peripheral firmware • iOS version • Environmental RF noise • Wi-Fi coexistence configuration Evidence Available We can provide: • Screenshots from a minimal test app showing packet counts • CSV files of packet timestamps • Source code for the BLE test app • Side-by-side comparison logs (affected vs unaffected device) All evidence is from the same app, built solely to measure packet timing. Additional Technical Notes • Issue persists after factory reset • Occurs without third-party BLE libraries (CoreBluetooth only) • Occurs regardless of foreground/background state • Not correlated with MTU size • Appears threshold-based (~33–40 Hz) • Appears device-specific, not model-wide

Does Bluetooth work in the background in iOS 26?

I have a standalone Apple Watch app that uses Bluetooth with the bluetooth-central background mode. It seems that in watchOS 26.2, once the system terminates the BLE connection after background allowance is exceeded, the app never regains background BLE capability, even after the user returns to the foreground and interacts with it. This contradicts the documentation and the WWDC22 “Get timely alerts from Bluetooth devices on watchOS” session, which state that background BLE connectivity should be restored when the user brings the app back to the foreground. Does anyone have any insight into this behavior?