Core Bluetooth

RSS for tag

Communicate with Bluetooth 4.0 low energy devices using Core Bluetooth.

Posts under Core Bluetooth tag

161 Posts

Post

Replies

Boosts

Views

Activity

Caching bluetooth pairing keys, core bluetooth
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.
1
0
222
Jan ’26
CBCentralManager State Changes to PoweredOff After Using ASK for Accessory Setup
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.
5
3
775
Feb ’26
Core Bluetooth Advertising in Background
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
0
0
103
Dec ’25
CoreBluetooth Advertiser role CBPeripheralManager didSubscribeToCharacteristic: not getting invoked on iPhone 17 Air/Pro (iOS 26.1+)
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.)
3
0
216
Feb ’26
visionOS Bluetooth LE limited to 2 connections?
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.
1
0
119
Jan ’26
peripheralIsReadyToSendWriteWithoutResponse not be invoked when App into the background
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?
0
0
396
Jan ’26
BLE audio packet loss on iPhone 17 (Bluetooth 6 / N1) in real-time streaming
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
2
1
378
Jan ’26
Requesting guidance on long-running background BLE control triggered by server-side events
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.
0
0
191
Jan ’26
BLE Advertising in Background
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?
2
0
414
Feb ’26
Unexpected CoreBluetooth background suspension without active location updates
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
2
0
660
Feb ’26
Pair iOS Central with MacOS Peripheral for encrypted characteristic
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?
0
0
112
Feb ’26
Inter-app Communication with Third Party SDK
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?
3
0
397
Feb ’26
Background scanning for Bluetooth advertisements with LiveActivities on ios26
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
1
0
243
Feb ’26
BLE Scanning
iOS BLE Background Scanning Stops After Few Minutes to Hours Hi everyone, I'm developing a Flutter app using flutter_blue_plus that needs continuous BLE scanning in both foreground and background. Foreground scanning works perfectly, but background scanning stops after a few minutes (sometimes 1-2 hours). Current Implementation (iOS) Foreground Mode: Scans for 10 seconds with all target service UUIDs Batches and submits results every 10 seconds Works reliably ✅ Background Mode: Rotates through service UUIDs in batches of 7 Uses 1-minute batch intervals Maintains active location streaming (Geolocator.getPositionStream) Switches modes via AppLifecycleState observer // Background scanning setup await FlutterBluePlus.startScan( withServices: serviceUuids, // Batch of 7 UUIDs continuousUpdates: true, ); // Location streaming (attempt to keep app alive) LocationSettings( accuracy: LocationAccuracy.bestForNavigation, distanceFilter: 0, ); Lifecycle Management: AppLifecycleState.paused -> Start background mode AppLifecycleState.resumed -> Start foreground mode Questions: Is there a documented maximum duration for iOS background BLE scanning? My scanning stops inconsistently (few minutes to 2 hours). Does iOS require specific Background Modes beyond location updates to maintain BLE scanning? I have location streaming active but scanning still stops. Are there undocumented limitations when scanning with service UUIDs in background that might cause termination? Should I be using CoreBluetooth's state preservation/restoration instead of continuous scanning? Info.plist Configuration: <key>UIBackgroundModes</key> <array> <string>bluetooth-central</string> <string>location</string> </array> Additional Context: Total service UUIDs: ~20-50 (varies by company) Scanning in batches of 7 to work around potential limitations Android version works fine with foreground service Location permission: Always iOS 14+ target Any insights on iOS BLE background limitations or best practices would be greatly appreciated. Thanks!
1
0
155
Feb ’26
iOS App never gets Bluetooth connection
I am developing an iOS App for a Bluetooth peripheral using SwiftUI with Swift 5 or 6. I have a few past attempts that got so far (connected to a peripheral), and some downloaded examples that connect to peripherals. Lately (last month or so), my current attempt never gets BleManager to start, and every attempt ends at my View that says 'please enable Bluetooth'. The Xcode console is totally blank with no print outputs. Coding Assistant suggested the init() in my @main structure could contain print("App initializing"), but even that never prints. Coding Assistant suggests: "• Open your project's Info.plist in Xcode. • Make sure UIApplicationSceneManifest is present and configured for SwiftUI, not referencing any storyboard. • Ensure UIMainStoryboardFile is not present (or blank)." but there is no info.plist because it is no longer required. Downloaded sample code runs and connects to peripherals, so Bluetooth is working on my iPhone and the Bluetooth device is accessible. My older attempts used to work, but now have the same problem. All attempts have "Enable Bluetooth to connect to Device" in the Privacy - Bluetooth Info.plist setting. Something is fundamentally wrong with many different code attempts. I have searched all the various settings for mention of SwiftUI or Storyboard, but not found them in working or failing projects. The downloaded code which works has minimum deployment iOS 14.0 and Swift Compiler Language Version Swift 5. My latest code attempt has minimum deployment iOS 16 and Swift 5. All code is target device iPhone (I am testing on iPhone 16e running iOS 26.2.1) and developing with Xcode 26.2 on MacBook Air M1 running the latest Tahoe. I do a Clean Build Folder before every test, and have tried re-starting both Mac and iPhone. How can my coding fail so spectacularly?
2
0
187
Feb ’26
BLE advertising/scanning communication broken on iPhone 17 — CBPeripheralManager + CBCentralManager workflow
Environment: iPhone 17 / iPhone 17 Pro (Apple N1 chip) iOS 26.x Xcode 26 Framework: Flutter app with native iOS BLE library (CoreBluetooth) We have a production IoT app that communicates with BLE nodes (Nordic, PIC, EnOcean peripherals) using an advertising/scanning-based protocol — not GATT connections. The app broadcasts commands via CBPeripheralManager (advertising service UUIDs) and receives responses by scanning with CBCentralManager (reading manufacturer data and service UUIDs from advertisement packets). This workflow has been reliable across all iPhone models from iPhone 8 through iPhone 16 Pro Max. On iPhone 17 devices, we are experiencing multiple failures in this workflow. Architecture: Sending commands: We use CBPeripheralManager.startAdvertising() with CBAdvertisementDataServiceUUIDsKey to broadcast a UUID-encoded command to nearby nodes. Receiving responses: We use CBCentralManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true]) and filter responses in centralManager(_:didDiscover:advertisementData:rssi:) by matching CBAdvertisementDataServiceUUIDsKey or CBAdvertisementDataManufacturerDataKey against expected UUID masks. Communication pattern: Advertise a command → stop advertiser → start scanner → wait for matching response → process result. Typical timeout is 1.5 seconds per exchange. Issues observed on iPhone 17: peripheralManagerDidStartAdvertising behaviour change After calling CBPeripheralManager.startAdvertising(:), the delegate callback peripheralManagerDidStartAdvertising(:error:) either fires with errors that did not occur on previous hardware, or advertising does not appear to reach the peripheral nodes at all. The same advertising payload works immediately when tested on iPhone 15/16. Is the N1 chip's Bluetooth 6 stack handling CBAdvertisementDataServiceUUIDsKey advertising differently? Are there new constraints on advertising payload size or format? Scanner returning fewer/no results with withServices: nil Our scanner uses scanForPeripherals(withServices: nil) because we need to read manufacturer data from advertisement packets and filter using a custom UUID mask. On iPhone 17, we observe significantly fewer didDiscover callbacks compared to iPhone 15/16 in the same physical environment, with the same nodes advertising. We understand that passing service UUIDs in withServices: is recommended, but our protocol requires reading raw manufacturer data bytes that aren't associated with a single service UUID — we use mask-based matching (e.g., filter mask 11110000-0000-0000-0000-000000000000 against scan results). Has the N1 chip changed the rate or filtering behaviour of unfiltered BLE scans? Is there a new throttling mechanism? Background scanning stops immediately When the app moves to background, scanning appears to stop entirely on iPhone 17 — even with bluetooth-central in UIBackgroundModes. On iPhone 16, background scanning continued (at reduced intervals) and delivered results for peripherals advertising filtered service UUIDs. Aggressive session termination on app backgrounding Our advertise-then-scan sequences (typically 1.5s round-trip) are being interrupted when the user briefly switches apps. The CBPeripheralManager stops advertising and the CBCentralManager stops scanning, causing timeout errors. This was not observed on previous iPhone models with the same iOS background mode configuration. Questions for Apple: Are there documented changes to CoreBluetooth behaviour on the N1 Bluetooth 6 chip that affect advertising-based (non-GATT) communication patterns? Has the scan response rate for scanForPeripherals(withServices: nil) been intentionally reduced on iPhone 17? Is CBCentralManagerOptionRestoreIdentifierKey now required for reliable background scanning on iPhone 17, or is this a known regression? Are there new advertising payload constraints (size, format, interval) that we should be aware of for the N1 chip? What we've tried: Added NSBluetoothAlwaysUsageDescription and NSBluetoothWhileInUseUsageDescription to Info.plist Confirmed Bluetooth permissions are granted Tested with identical BLE nodes that work on iPhone 15/16 Verified CBManagerState.poweredOn before all operations Any guidance or known workarounds would be greatly appreciated. Happy to provide sysdiagnose logs or a minimal reproducible sample project.
3
0
515
Feb ’26
Seeking advice consulting Bluetooth BLE iOS App build EXPO EAS. Native React.
I’m close to finishing my App build (using Rork.com) and need advice consulting on adding BLE Bluetooth functionality to connect to Cycling Sensors, speed cadence, watts, smart indoor cycling trainers, heart rate straps etc. My questions are as a complete beginner: 1: How much time is needed to set up BLE connections in Expo.dev using EAS build? 2: Where can I find a trustworthy tech to implement this? and on a second aspect for the app. I need someone to help set up REVENUECAT, for annual subscriptions. I’ve partly set it up for testing. How much time is needed here? many thanks for your time in advance for any help / assistance you’re able to provide. cherrs ben
0
0
107
Feb ’26
AirPods 4 Bluetooth Firmware Bug in L2CAP
Hello, I am a Bluetooth Engineer at Google investigating an interoperability bug between an Android device and AirPods 4. When requesting an L2CAP connection (with PSM = AVDTP) to the AirPods during SDP service discovery, The AirPods L2CAP layer incorrectly responds with a "refused - no resources available" status followed by a Pending status and a Success status. This violates the specification, which says that the request has been fully rejected after the refused status and should not receive followup responses. I suspect the "no resources available" response is a bug. This prevents A2DP from working with the AirPods. This bug does not exist with AirPods 2 firmware. Here is a packet capture: 1602 1969-12-31 16:07:04.805261 0.062473 localhost () Apple_6b:db:09 (AirPods) L2CAP 17 Sent Connection Request (AVDTP, SCID: 0x22c6) 1603 1969-12-31 16:07:04.810953 0.005692 controller host HCI_EVT 8 Rcvd Number of Completed Packets 1604 1969-12-31 16:07:04.811078 0.000125 Apple_6b:db:09 (AirPods) localhost () SDP 27 Rcvd Service Search Attribute Request : Device Information: [Bluetooth Profile Descriptor List 0x0009] 1605 1969-12-31 16:07:04.821249 0.010171 localhost () Apple_6b:db:09 (AirPods) SDP 19 Sent Service Search Attribute Response 1606 1969-12-31 16:07:04.876396 0.055147 controller host HCI_EVT 8 Rcvd Number of Completed Packets 1607 1969-12-31 16:07:04.876464 0.000068 Apple_6b:db:09 (AirPods) localhost () L2CAP 21 Rcvd Connection Response - Refused - no resources available (SCID: 0x22c6) 1608 1969-12-31 16:07:04.942539 0.066075 Apple_6b:db:09 (AirPods) localhost () SDP 41 Rcvd Service Search Attribute Request : Unknown: [Bluetooth Profile Descriptor List 0x0009] 1609 1969-12-31 16:07:04.951052 0.008513 localhost () Apple_6b:db:09 (AirPods) SDP 19 Sent Service Search Attribute Response 1610 1969-12-31 16:07:05.010605 0.059553 controller host HCI_EVT 8 Rcvd Number of Completed Packets 1611 1969-12-31 16:07:05.080593 0.069988 Apple_6b:db:09 (AirPods) localhost () SDP 27 Rcvd Service Search Attribute Request : GATT: [Bluetooth Profile Descriptor List 0x0009] 1612 1969-12-31 16:07:05.087636 0.007043 localhost () Apple_6b:db:09 (AirPods) SDP 19 Sent Service Search Attribute Response 1613 1969-12-31 16:07:05.209417 0.121781 controller host HCI_EVT 8 Rcvd Number of Completed Packets 1614 1969-12-31 16:07:05.279491 0.070074 Apple_6b:db:09 (AirPods) localhost () L2CAP 21 Rcvd Connection Response - Pending (SCID: 0x22c6) 1615 1969-12-31 16:07:05.280731 0.001240 Apple_6b:db:09 (AirPods) localhost () L2CAP 21 Rcvd Connection Response - Success (SCID: 0x22c6, DCID: 0x0406) Please file this bug with the AirPods Bluetooth team.
1
0
264
Feb ’26
Caching bluetooth pairing keys, core bluetooth
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.
Replies
1
Boosts
0
Views
222
Activity
Jan ’26
CBCentralManager State Changes to PoweredOff After Using ASK for Accessory Setup
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.
Replies
5
Boosts
3
Views
775
Activity
Feb ’26
Core Bluetooth Advertising in Background
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
Replies
0
Boosts
0
Views
103
Activity
Dec ’25
CoreBluetooth Advertiser role CBPeripheralManager didSubscribeToCharacteristic: not getting invoked on iPhone 17 Air/Pro (iOS 26.1+)
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.)
Replies
3
Boosts
0
Views
216
Activity
Feb ’26
visionOS Bluetooth LE limited to 2 connections?
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.
Replies
1
Boosts
0
Views
119
Activity
Jan ’26
peripheralIsReadyToSendWriteWithoutResponse not be invoked when App into the background
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?
Replies
0
Boosts
0
Views
396
Activity
Jan ’26
BLE audio packet loss on iPhone 17 (Bluetooth 6 / N1) in real-time streaming
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
Replies
2
Boosts
1
Views
378
Activity
Jan ’26
Missing Bluetooth background mode
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.
Replies
0
Boosts
0
Views
190
Activity
Jan ’26
Requesting guidance on long-running background BLE control triggered by server-side events
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.
Replies
0
Boosts
0
Views
191
Activity
Jan ’26
BLE Advertising in Background
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?
Replies
2
Boosts
0
Views
414
Activity
Feb ’26
Unexpected CoreBluetooth background suspension without active location updates
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
Replies
2
Boosts
0
Views
660
Activity
Feb ’26
Pair iOS Central with MacOS Peripheral for encrypted characteristic
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?
Replies
0
Boosts
0
Views
112
Activity
Feb ’26
Inter-app Communication with Third Party SDK
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?
Replies
3
Boosts
0
Views
397
Activity
Feb ’26
Background scanning for Bluetooth advertisements with LiveActivities on ios26
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
Replies
1
Boosts
0
Views
243
Activity
Feb ’26
BLE Scanning
iOS BLE Background Scanning Stops After Few Minutes to Hours Hi everyone, I'm developing a Flutter app using flutter_blue_plus that needs continuous BLE scanning in both foreground and background. Foreground scanning works perfectly, but background scanning stops after a few minutes (sometimes 1-2 hours). Current Implementation (iOS) Foreground Mode: Scans for 10 seconds with all target service UUIDs Batches and submits results every 10 seconds Works reliably ✅ Background Mode: Rotates through service UUIDs in batches of 7 Uses 1-minute batch intervals Maintains active location streaming (Geolocator.getPositionStream) Switches modes via AppLifecycleState observer // Background scanning setup await FlutterBluePlus.startScan( withServices: serviceUuids, // Batch of 7 UUIDs continuousUpdates: true, ); // Location streaming (attempt to keep app alive) LocationSettings( accuracy: LocationAccuracy.bestForNavigation, distanceFilter: 0, ); Lifecycle Management: AppLifecycleState.paused -> Start background mode AppLifecycleState.resumed -> Start foreground mode Questions: Is there a documented maximum duration for iOS background BLE scanning? My scanning stops inconsistently (few minutes to 2 hours). Does iOS require specific Background Modes beyond location updates to maintain BLE scanning? I have location streaming active but scanning still stops. Are there undocumented limitations when scanning with service UUIDs in background that might cause termination? Should I be using CoreBluetooth's state preservation/restoration instead of continuous scanning? Info.plist Configuration: <key>UIBackgroundModes</key> <array> <string>bluetooth-central</string> <string>location</string> </array> Additional Context: Total service UUIDs: ~20-50 (varies by company) Scanning in batches of 7 to work around potential limitations Android version works fine with foreground service Location permission: Always iOS 14+ target Any insights on iOS BLE background limitations or best practices would be greatly appreciated. Thanks!
Replies
1
Boosts
0
Views
155
Activity
Feb ’26
iOS App never gets Bluetooth connection
I am developing an iOS App for a Bluetooth peripheral using SwiftUI with Swift 5 or 6. I have a few past attempts that got so far (connected to a peripheral), and some downloaded examples that connect to peripherals. Lately (last month or so), my current attempt never gets BleManager to start, and every attempt ends at my View that says 'please enable Bluetooth'. The Xcode console is totally blank with no print outputs. Coding Assistant suggested the init() in my @main structure could contain print("App initializing"), but even that never prints. Coding Assistant suggests: "• Open your project's Info.plist in Xcode. • Make sure UIApplicationSceneManifest is present and configured for SwiftUI, not referencing any storyboard. • Ensure UIMainStoryboardFile is not present (or blank)." but there is no info.plist because it is no longer required. Downloaded sample code runs and connects to peripherals, so Bluetooth is working on my iPhone and the Bluetooth device is accessible. My older attempts used to work, but now have the same problem. All attempts have "Enable Bluetooth to connect to Device" in the Privacy - Bluetooth Info.plist setting. Something is fundamentally wrong with many different code attempts. I have searched all the various settings for mention of SwiftUI or Storyboard, but not found them in working or failing projects. The downloaded code which works has minimum deployment iOS 14.0 and Swift Compiler Language Version Swift 5. My latest code attempt has minimum deployment iOS 16 and Swift 5. All code is target device iPhone (I am testing on iPhone 16e running iOS 26.2.1) and developing with Xcode 26.2 on MacBook Air M1 running the latest Tahoe. I do a Clean Build Folder before every test, and have tried re-starting both Mac and iPhone. How can my coding fail so spectacularly?
Replies
2
Boosts
0
Views
187
Activity
Feb ’26
BLE advertising/scanning communication broken on iPhone 17 — CBPeripheralManager + CBCentralManager workflow
Environment: iPhone 17 / iPhone 17 Pro (Apple N1 chip) iOS 26.x Xcode 26 Framework: Flutter app with native iOS BLE library (CoreBluetooth) We have a production IoT app that communicates with BLE nodes (Nordic, PIC, EnOcean peripherals) using an advertising/scanning-based protocol — not GATT connections. The app broadcasts commands via CBPeripheralManager (advertising service UUIDs) and receives responses by scanning with CBCentralManager (reading manufacturer data and service UUIDs from advertisement packets). This workflow has been reliable across all iPhone models from iPhone 8 through iPhone 16 Pro Max. On iPhone 17 devices, we are experiencing multiple failures in this workflow. Architecture: Sending commands: We use CBPeripheralManager.startAdvertising() with CBAdvertisementDataServiceUUIDsKey to broadcast a UUID-encoded command to nearby nodes. Receiving responses: We use CBCentralManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true]) and filter responses in centralManager(_:didDiscover:advertisementData:rssi:) by matching CBAdvertisementDataServiceUUIDsKey or CBAdvertisementDataManufacturerDataKey against expected UUID masks. Communication pattern: Advertise a command → stop advertiser → start scanner → wait for matching response → process result. Typical timeout is 1.5 seconds per exchange. Issues observed on iPhone 17: peripheralManagerDidStartAdvertising behaviour change After calling CBPeripheralManager.startAdvertising(:), the delegate callback peripheralManagerDidStartAdvertising(:error:) either fires with errors that did not occur on previous hardware, or advertising does not appear to reach the peripheral nodes at all. The same advertising payload works immediately when tested on iPhone 15/16. Is the N1 chip's Bluetooth 6 stack handling CBAdvertisementDataServiceUUIDsKey advertising differently? Are there new constraints on advertising payload size or format? Scanner returning fewer/no results with withServices: nil Our scanner uses scanForPeripherals(withServices: nil) because we need to read manufacturer data from advertisement packets and filter using a custom UUID mask. On iPhone 17, we observe significantly fewer didDiscover callbacks compared to iPhone 15/16 in the same physical environment, with the same nodes advertising. We understand that passing service UUIDs in withServices: is recommended, but our protocol requires reading raw manufacturer data bytes that aren't associated with a single service UUID — we use mask-based matching (e.g., filter mask 11110000-0000-0000-0000-000000000000 against scan results). Has the N1 chip changed the rate or filtering behaviour of unfiltered BLE scans? Is there a new throttling mechanism? Background scanning stops immediately When the app moves to background, scanning appears to stop entirely on iPhone 17 — even with bluetooth-central in UIBackgroundModes. On iPhone 16, background scanning continued (at reduced intervals) and delivered results for peripherals advertising filtered service UUIDs. Aggressive session termination on app backgrounding Our advertise-then-scan sequences (typically 1.5s round-trip) are being interrupted when the user briefly switches apps. The CBPeripheralManager stops advertising and the CBCentralManager stops scanning, causing timeout errors. This was not observed on previous iPhone models with the same iOS background mode configuration. Questions for Apple: Are there documented changes to CoreBluetooth behaviour on the N1 Bluetooth 6 chip that affect advertising-based (non-GATT) communication patterns? Has the scan response rate for scanForPeripherals(withServices: nil) been intentionally reduced on iPhone 17? Is CBCentralManagerOptionRestoreIdentifierKey now required for reliable background scanning on iPhone 17, or is this a known regression? Are there new advertising payload constraints (size, format, interval) that we should be aware of for the N1 chip? What we've tried: Added NSBluetoothAlwaysUsageDescription and NSBluetoothWhileInUseUsageDescription to Info.plist Confirmed Bluetooth permissions are granted Tested with identical BLE nodes that work on iPhone 15/16 Verified CBManagerState.poweredOn before all operations Any guidance or known workarounds would be greatly appreciated. Happy to provide sysdiagnose logs or a minimal reproducible sample project.
Replies
3
Boosts
0
Views
515
Activity
Feb ’26
Can I trigger AudioRecordingIntent from a bluetooth device
I have a BLE device which my app connects to and can detect button presses. On a button press, I want my app to start recording using the AudioRecordingIntent. But my app doesn't work and throws a background error. Is there any reliable way I can get the app to start recording audio in the background?
Replies
2
Boosts
0
Views
263
Activity
Feb ’26
Seeking advice consulting Bluetooth BLE iOS App build EXPO EAS. Native React.
I’m close to finishing my App build (using Rork.com) and need advice consulting on adding BLE Bluetooth functionality to connect to Cycling Sensors, speed cadence, watts, smart indoor cycling trainers, heart rate straps etc. My questions are as a complete beginner: 1: How much time is needed to set up BLE connections in Expo.dev using EAS build? 2: Where can I find a trustworthy tech to implement this? and on a second aspect for the app. I need someone to help set up REVENUECAT, for annual subscriptions. I’ve partly set it up for testing. How much time is needed here? many thanks for your time in advance for any help / assistance you’re able to provide. cherrs ben
Replies
0
Boosts
0
Views
107
Activity
Feb ’26
AirPods 4 Bluetooth Firmware Bug in L2CAP
Hello, I am a Bluetooth Engineer at Google investigating an interoperability bug between an Android device and AirPods 4. When requesting an L2CAP connection (with PSM = AVDTP) to the AirPods during SDP service discovery, The AirPods L2CAP layer incorrectly responds with a "refused - no resources available" status followed by a Pending status and a Success status. This violates the specification, which says that the request has been fully rejected after the refused status and should not receive followup responses. I suspect the "no resources available" response is a bug. This prevents A2DP from working with the AirPods. This bug does not exist with AirPods 2 firmware. Here is a packet capture: 1602 1969-12-31 16:07:04.805261 0.062473 localhost () Apple_6b:db:09 (AirPods) L2CAP 17 Sent Connection Request (AVDTP, SCID: 0x22c6) 1603 1969-12-31 16:07:04.810953 0.005692 controller host HCI_EVT 8 Rcvd Number of Completed Packets 1604 1969-12-31 16:07:04.811078 0.000125 Apple_6b:db:09 (AirPods) localhost () SDP 27 Rcvd Service Search Attribute Request : Device Information: [Bluetooth Profile Descriptor List 0x0009] 1605 1969-12-31 16:07:04.821249 0.010171 localhost () Apple_6b:db:09 (AirPods) SDP 19 Sent Service Search Attribute Response 1606 1969-12-31 16:07:04.876396 0.055147 controller host HCI_EVT 8 Rcvd Number of Completed Packets 1607 1969-12-31 16:07:04.876464 0.000068 Apple_6b:db:09 (AirPods) localhost () L2CAP 21 Rcvd Connection Response - Refused - no resources available (SCID: 0x22c6) 1608 1969-12-31 16:07:04.942539 0.066075 Apple_6b:db:09 (AirPods) localhost () SDP 41 Rcvd Service Search Attribute Request : Unknown: [Bluetooth Profile Descriptor List 0x0009] 1609 1969-12-31 16:07:04.951052 0.008513 localhost () Apple_6b:db:09 (AirPods) SDP 19 Sent Service Search Attribute Response 1610 1969-12-31 16:07:05.010605 0.059553 controller host HCI_EVT 8 Rcvd Number of Completed Packets 1611 1969-12-31 16:07:05.080593 0.069988 Apple_6b:db:09 (AirPods) localhost () SDP 27 Rcvd Service Search Attribute Request : GATT: [Bluetooth Profile Descriptor List 0x0009] 1612 1969-12-31 16:07:05.087636 0.007043 localhost () Apple_6b:db:09 (AirPods) SDP 19 Sent Service Search Attribute Response 1613 1969-12-31 16:07:05.209417 0.121781 controller host HCI_EVT 8 Rcvd Number of Completed Packets 1614 1969-12-31 16:07:05.279491 0.070074 Apple_6b:db:09 (AirPods) localhost () L2CAP 21 Rcvd Connection Response - Pending (SCID: 0x22c6) 1615 1969-12-31 16:07:05.280731 0.001240 Apple_6b:db:09 (AirPods) localhost () L2CAP 21 Rcvd Connection Response - Success (SCID: 0x22c6, DCID: 0x0406) Please file this bug with the AirPods Bluetooth team.
Replies
1
Boosts
0
Views
264
Activity
Feb ’26