Hi all, I'm encountering a BLE issue with the newer iPad models featuring the A16 Bionic chip (e.g., iPad 11th Gen). I have an iOS application that runs as a BLE peripheral, and it used to work flawlessly with various central devices. 📱 Device Specs Model: iPad (A16 Bionic) OS: iPadOS 18.6 ✅ Working Setup (Before): iOS app acts as a BLE peripheral (advertises a custom service). Central device (Windows/Linux/Android) could: Discover advertisements Connect to the peripheral Exchange MTU Discover GATT services Communicate bidirectionally ❌ Issue with iPad A16 (Newer Devices): Central device receives advertisements and connects. MTU exchange request is sent by central, but iPad A16 does not respond. The BLE link remains active but only transmits empty PDUs, and communication never proceeds. Same issue observed with third-party apps like BLE HID keyboard — they also fail to connect or communicate on A16 iPads but work on older devices (e.g., iPad 10th Gen and below). 🔍 Debugging So Far: Confirmed that MTU Exchange Request is compliant (Client Rx MTU = 527). Works fine with iPad 10th Gen and earlier. Works with Android, Windows, and even Linux central stacks with older iPads. A16-based iPads seem to silently drop or ignore the MTU request. 🧪 Suspected Cause: Possible regression or behavioral change in LE Privacy handling on newer iPads. Possibly tied to iPadOS version or Bluetooth controller firmware. 🙏 Looking for: Anyone else facing similar BLE issues on iPads with A16? Any known changes to BLE LE Privacy, MTU negotiation, or connection behavior in iPadOS on A16 devices? Any workarounds, entitlements, or configuration changes that fixed the issue? Would appreciate any insights or suggestions. Thank you!

I'm encountering an issue related to BLE device discovery on iOS. I have a BLE peripheral device that I initially connected to using an iOS device. After this connection, the BLE device's advertised name was programmatically changed by the peripheral. Now, when I try to scan for this device using other iOS devices, it does not appear in the scan results in most apps — including nRF Connect and our own custom BLE app that uses CoreBluetooth. A few observations: The device is definitely powered on and advertising (confirmed via Android). The name change is reflected correctly on Android and on the iOS device that originally connected to it. Other iOS devices no longer see the device in their scan list.

I am developing an app that communicates with external BLE device over GATT. The device has a secure-read characteristic exposing some of it's data and requires pairing/bonding in order to communicate with it. I was able to pair and connect with the device using AccessorySetupKit and .bluetoothPairingLE option: let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = CBUUID(string: serviceUUID) descriptor.supportedOptions = [.bluetoothPairingLE] let picketItem = ASPickerDisplayItem(name: name, productImage: image, descriptor: descriptor) In this case when setting up accessory, I was prompted to compare passkeys and after confirming I can read the characteristic etc. Then I tried adding .confirmAuthorization to picker item and problems started: let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = CBUUID(string: serviceUUID) descriptor.supportedOptions = [.bluetoothPairingLE] let picketItem = ASPickerDisplayItem(name: name, productImage: image, desc pickerItem.setupOptions = [.confirmAuthorization] When setting up, I can see a passkey to be confirmed, but when confirmed the setup ui get's suck in loading state. Under the hood in logs, I can see that my app has connected to peripheral and was able to read the characteristic. I am unsure why the ui is stuck in loading state in this case. What is the difference when using .confirmAuthorization option and what should be the proper flow of events to setup accessory and then access protoected characteristic?

Hello Apple Developer Community and Apple Engineers, I'm working on a CoreBluetooth-based iOS application and struggling to find clear, official guidance on best practices for unit testing CoreBluetooth functionality. I'd appreciate any insights from the community and especially from Apple engineers on the recommended approaches. Background & Challenges: Our team has encountered several challenges when trying to implement comprehensive testing for our CoreBluetooth code: Subclassing Restrictions: Apple's documentation explicitly states "Don't subclass any of the classes of the Core Bluetooth framework. Overriding these classes isn't supported and results in undefined behavior." This makes traditional mocking approaches (creating mock subclasses of CBCentralManager, CBPeripheral, etc.) problematic for unit testing. Integration vs Unit Testing Dilemma: We currently use integration tests with third-party libraries like Nordic Semiconductor's CoreBluetoothMock, which work well for end-to-end testing but aren't true unit tests. They test the interaction between our code and the (mocked) CoreBluetooth stack rather than testing individual methods in isolation. Delegate Method Testing: Our code implements CBCentralManagerDelegate and CBPeripheralDelegate protocols. Testing these delegate methods in isolation is challenging because: The methods receive CBCentralManager/CBPeripheral parameters that we can't mock via subclassing Using third-party mocking frameworks makes them integration tests, not unit tests Testing the business logic within these methods requires the actual CoreBluetooth objects Simulator Limitations: The only official Apple documentation we found about CoreBluetooth testing is Technical Note TN2295, which is marked as "retired" and from 2012. It describes a complex simulator setup requiring physical USB adapters, suggesting simulator-only testing isn't fully supported. Specific Questions: What are Apple's current official recommendations for testing CoreBluetooth applications? Should we focus on device testing, integration testing with mocking libraries, or are there other approaches we should consider? For unit testing: How can we test individual delegate methods and business logic without violating the "no subclassing" restriction? Are there patterns or architectures that make CoreBluetooth code more unit-testable? Testing strategy: Should CoreBluetooth applications primarily rely on integration tests rather than traditional unit tests? Is this an acceptable trade-off given the hardware-dependent nature of Bluetooth? Simulator support: Is there current, supported functionality for testing CoreBluetooth applications in the simulator, or should all testing be done on physical devices? Current Approach: We're currently using: Integration tests with CoreBluetoothMock for comprehensive workflow testing Limited unit tests for business logic that we can extract from delegate methods Physical device testing for final validation This works but feels incomplete compared to the unit testing coverage we achieve in other parts of our application. Request: Any guidance from Apple engineers on the intended/recommended approach for testing CoreBluetooth applications would be incredibly valuable. Even confirmation that "integration testing with physical devices is the primary recommended approach" would help clarify our testing strategy. Thank you for any insights you can share! Environment: iOS 17+ Xcode 15+ Swift 5.9+

Hello, I want to try develop hearing aid based on stm32 with BLE Module. If I want to only stream music from iPhone, does I need mfi certification? And I want to develop application with changing program on device

We're seeing a consistent issue where iPads with the A16 chip fail to connect to our BLE device, which uses a Silicon Labs chip running Gecko SDK 3.x. All other Apple devices — including older iPads and iPhones — connect without any problems. According to Silicon Labs, the issue stems from the iPad A16 sending an LL_CHANNEL_REPORTING_IND message (opcode 0x28) during connection establishment: Per Silicon Labs: "Currently the iPad 16 will send a message for LL_CHANNEL_REPORTING_IND (opcode 0x28). This is a feature that is not supported in Gecko SDK 3.x. Shortly after, the BLE module responds with an 'Unknown Response' (opcode 0x07), indicating that it does not support opcode 0x28 After this exchange the iPad stops sending meaningful transactions to the BLE module and eventually closes the connection. The BLE Module is responding to this unknown request as specified in the BT Core Spec Volume 6 Part B." Unfortunately, the firmware on these BLE modules cannot be updated remotely, and we've already shipped several thousand units to customers. Given how widely Silicon Labs' BLE modules are deployed, we suspect this issue could be affecting many other developers and products as well. We’re hoping Apple might offer a workaround or allow us access — even internally or unofficially — to suppress or bypass this feature in CoreBluetooth for this specific scenario. For example, is there a way to disable LL_CHANNEL_REPORTING_IND or instruct the stack to ignore the unknown response from the peripheral? We’re open to any workaround via CoreBluetooth (even private APIs or entitlements, if necessary) that would allow us to preserve compatibility without a mass recall. If there's an Apple engineer monitoring this, we'd be extremely grateful for guidance or escalation. Thank you!

Hi everyone, while testing HKWorkoutSession with HKLiveWorkoutBuilder on iOS 26 Beta (cycling workout), I noticed the following behavior: – Starting a cycling HKWorkoutSession automatically connects to my Bluetooth heart rate monitor and records HR into HealthKit ✅ – However, my Bluetooth cycling power meter and cadence sensor (standard BLE Cycling Power & CSC services) are not connected automatically, and no data is recorded into HealthKit ❌ On Apple Watch, when starting a cycling workout, these sensors do connect automatically and their data is written to HealthKit — which is exactly what I would expect on iOS as well. Question: Is this by design, or is support for power and cadence sensors planned for iOS in the same way as on watchOS? Or do we, as developers, need to implement the BLE Cycling Power and CSC profiles ourselves (via CoreBluetooth) if we want these metrics? Environment: – iOS 26 Beta – HKWorkoutSession & HKLiveWorkoutBuilder (cycling) – Bluetooth HRM connects automatically – BLE power & cadence sensors do not This feature would make it much easier to develop cycling apps with full HealthKit integration, and also create a more consistent user experience compared to watchOS. Thanks for any insights!

first post here and this is kinda a long shot. I’m working on a custom keypad project for a young man with some mobility issues that unfortunately prevents gestrue and voice control as UI options. id like to see if I can pull track metadata via a Bluetooth connection into a custom keyboard with a small screen. I know hid doesn’t support this but I was hoping maybe the API for iOS’s blueprint remote app could be leveraged. I haven’t don’t much with Apple previousl. Usually Roku and Crestron implantations but I’m hoping to see if I can accomplish something with Apple, without needing to implement any IP connection.

Hello everyone, We are building an iOS app using React Native that connects to a custom Bluetooth Low Energy (BLE) accessory. The accessory continuously sends small chunks of audio data to the app through BLE (basically every time the user speaks), which are then streamed in real time to our server via WebSocket for transcription and processing. We need to know if the following behavior is allowed by iOS runtime and App Store review policies: Can the app open a WebSocket connection in the background (not permanently, just briefly, several times a day) triggered by BLE activity from a registered accessory? Is there a limit to this? Clarifications: The app is not expected to remain permanently awake. Only during accessory-triggered events. WebSocket is required due to the real-time nature of streaming STT and delivering quick responses (via notifications). If allowed, are there any specific Info.plist declarations or entitlements we must include? Thanks in advance! Fran

Hi there! I'm developing a dual-mode bluetooth accessory and would like to pair it through AccessorySetupKit. I'm using an ESP32 with Bluekitchen btstack. This supports CTKD, which seems to be a requirement for the Bluetooth transport bridging according the WWDC19 session 901. I've been in contact with the btstack developer and verified that I can get the device to generate an LTK for the classic transport when reading an encrypted attribute. I'm not able to get this to work with the bluetoothTransportBriding option with AccessorySetupKit though. What I've found so far is that if I omit the .bluetoothTransportBriding option during pairing I will get a pairing request when I read an encrypted attribute after connecting with the CBConnectPeripheralOptionEnableTransportBridgingKey option. If I accept this request it seems like the system automatically brings up the A2DP profile. However if I include .bluetoothTransportBriding and/or .bluetoothPairingLE this option does not pop up, but the system does not bring up the A2DP profile. In this case things seem to end up in a weird situation where the device doesn't show up for pairing in Bluetooth Settings either, making it impossible to manually connect for A2DP. Based on the AccessorySetupKit example from WWDC24 I've created a dice accessory firmware for ESP32 using btstack. The code for this is available here: https://github.com/ljodal/esp32-btstack-ctkd-test I've also tweaked the AccessorySetupKit example app for iOS to add the ASAccessory.SupportOptions. The code for that is available here: https://github.com/ljodal/accessorysetupkit-ctkd-test Is there any documentation available anywhere on what is expected of the device for Bluetooth Transport Bridging to work with AccessorySetupKit?

Hi, We're receiving data via centralManager.centralManager.scanForPeripherals, with no options or filtering (for now), and in the func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) callback, we get advertisementData for each bluetooth device found. But, I know one of my BLE devices is sending an Eddystone TLM payload, which generally is received into the kCBAdvDataServiceData part of the advertisementData dictionary, but, it doesn't show up. What is happening however (when comparing to other devices that do show that payload), is I've noticed the "isConnectable" part is false, and others have it true. Technically we're not "connecting" as such as we're simply reading passive advertisement data, but does that have any bearing on how CoreBluetooth decides to build up it's AdvertisementData response? Example (with serviceData; and I know this has Eddystone TLM) ["kCBAdvDataLocalName": FSC-BP105N, "kCBAdvDataRxPrimaryPHY": 1, "kCBAdvDataServiceUUIDs": <__NSArrayM 0x300b71f80>( FEAA, FEF5 ) , "kCBAdvDataTimestamp": 773270526.26279, "kCBAdvDataServiceData": { FFF0 = {length = 11, bytes = 0x36021892dc0d3015aeb164}; FEAA = {length = 14, bytes = 0x20000be680000339ffa229bbce8a}; }, "kCBAdvDataRxSecondaryPHY": 0, "kCBAdvDataIsConnectable": 1] Vs This also has Eddystone TLM configured ["kCBAdvDataLocalName": 100FA9FD-7000-1000, "kCBAdvDataIsConnectable": 0, "kCBAdvDataRxPrimaryPHY": 1, "kCBAdvDataRxSecondaryPHY": 0, "kCBAdvDataTimestamp": 773270918.97273] Any insight would be great to understand if the presence of other flags drive the exposure of ServiceData or not...

We've been developing an iOS app in Swift for several years that run on iPad tablets in which our proprietary device emits EEG signals via BLE to the app running on the iPad tablet. The device emits the data as BLE notification messages in which the MTU is set to the maximum size that is allowed between our device and the iPad. Our device when communicating with the app running on a 10th generation iPad running iOS 18.5 it takes less than 200ms to transmit an interval of EEG signals which occurs at 500ms. Under the same conditions same version of iOS & app and the same device but using an iPad 11th generation, it takes anywhere from 800ms to 1.1 seconds (4x to 5x) to transmit an interval. Our device transmits the EEG signal using several ATT notification messages using the maximum MTU size. We are perplexed about such a huge step down in performance when running on the iPad 11th generation tablets. iPad generation Chipset Firmware -------------------------------------------------------------- 10th BCM_4387 22.5.614.3457 11th SRS_7923 HCI Rev. 2504 sub. 5003 We know that the 10th generation iPad used chipset manufactured by Broadcom. Whereas the iPad 11th generation that we've received uses a SRS chipset in which I'm unfamiliar with that chipset's manufacturer. We question if this performance degradation is due from the chipset manufacturer, the firmware revision when using attribute notifications messages over BLE in such a context. Using PacketLogger as to log the communication between the iPad tablets and our device and after analysis we haven't found anything that identifies difference in configuration settings that are exchanged between our device and iPad tablets that account for this performance degradation. Fortunately, our device is designed to work in complex environments & contexts and thus it has mechanisms accounting for transmission delays and interferences. I'd appreciate if any other Apple Developer or Apple staff is aware of the degradation when transmitting BLE attribute notification messages with the newer Apple devices using this series of chipset. If so, then: Are there any recommendations of solutions to improve this latency? Is this is being addressed for iPad 11th generation tablets? Regards, Steven Belbin Principal Developer at NeuroServo Inc.

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

When establishing a Bluetooth connection and subscribing to feature values, the log shows a subscription failure with the error: did fail to update notification state: The handle is invalid.

I am very happy to see that HealthKit with OS26 is bringing HKLiveWorkoutDataSource to iOS and iPadOS. I have been replicating a similar type for the last several years for users that only have an iPhone. I did notice that the data types that the different platform data sources collect automatically is different. That makes sense if you think exclusively about what the device can actually capture. Bluetooth HRM is the only Bluetooth SIG profile that is out-of-the-box supported for Apple Health on iOS and iPadOS (right?). Whereas watchOS 10 got all of the cycling sensors (woohoo!). It would be great if the types to collect were the same across platforms even if the device couldn't collect the data now, because then in the future when / if new sensor support is added, it will be transparent to developers. Fantastic. Easier life as an indie / third party developer. At least that is the idea. And yes, I know I can also write Core Bluetooth code and roll my own SIG implementation for the cycling profiles, but Apple already has this code in one os, 'just copy it, it will be easy'. I know that isn't the reality especially against the new ASK framework, but one can hope and dream right? Imagine how many more apps would contribute that data if it was supported out of the box. An alternative, GitHub is a great place for Apple to share their Core Bluetooth implementation of the SIG profiles :). Just another thought. Here are some feedbacks related to this: FB17931751 - HealthKit: Add built-in support for cycling sensors on iOS and iPadOS - copy paste the code from watchOS. It will be easy they said (June 2025) FB12323089 - CoreBluetooth / Health / Bluetooth Settings: Add support for cycling sensors announced in watchOS 10 to iOS and iPadOS 17 (June 2023) FB14311218 - HealthKit: Expected outdoor cycling to include .cyclingSpeed quantity type as a default HKLiveWorkoutDataSource type to collect (July 2024) FB14978701 - Bluetooth / HealthKit / Fitness: Expose information about the user specified for Apple Watch paired Cycing Speed Sensor like isConnected and wheelCircumference values (August 2024) FB18402258 - HealthKit: HKLiveWorkoutDataSource should collect same types on iOS and watchOS even if device cannot produce data today (June 2025) FB14236080 - Developer Documentation / HealthKit: Update documentation for HKLiveWorkoutDataSource typesToCollect for which sample types are automatically collected by watchOS 10 and 11 (July 2024) Tangentially related: FB10281304 - HealthKit: Add HKActivityTypes canoeBikeRun and kayakBikeRun (June 2022) FB10281349 - HealthKit: Add HKActivityType walkCanoeWalk and walkKayakWalk (June 2022) FB7807993 - Add HKQuantityTypeIdentifier.paddleDistance for canoeing, kayaking, etc type workouts (June 2020) FB12508654 - HealthKit / Settings / Bluetooth / Workouts: Cycling sensor support doesn't allow for 'bike selection' in use case of multiple bikes and multiple sensors (borrow a bike to ride together) - production usability issue (July 2023)

Hi, I am developing an app that checks if Bluetooth is available on the device or not (does not actually use any Bluetooth capabilities). The only CoreBluetooth API's that I use are: CBCentralManager the state property of the CBCentralManager centralManagerDidUpdateState When I am testing, I experience different behaviors on my test devices. On an iPhone 15 iOS 18.5, the app works fine. However, on an iPhone 13 iOS 18.3.2, the app crashes with the following error: This app has crashed because it attempted to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSBluetoothAlwaysUsageDescription key with a string value explaining to the user how the app uses this data. Why is this permission required on my iPhone 13 iOS 18.3.2, but not my iPhone 15 iOS 18.5? Why do I experience different behavior on different iPhone configurations?

I have a BLE device and I'm developing an iOS app that communicates with that device. The device has a characteristic that has both notify and indicate properties, and sends some messages via notify and others via indicate, therefore I cannot use setNotifyValue. If the specified characteristic’s configuration allows both notifications and indications, calling this method enables notifications only. Is there any way to enable simultaneously both notify and indicate for the same characteristic?

When I startAdvertising, my localName is long，Will not be truncated and the type is 0X09; self.advertisementData = @{CBAdvertisementDataLocalNameKey: localDevName, CBAdvertisementDataServiceUUIDsKey: @[[CBUUID UUIDWithString:serviceUUID]] }; [self.peripheralManager startAdvertising:self.advertisementData]; IOS 18.5: The service uuids in ADV_IND occupies 24 bytes, the local name in SCAN_RESP is 20 bytes in size and has not been truncated, and there is no manufacturer specific data in SCAN_RESP;You can view the following image： But in IOS26, why is the local name truncated to only 6 bytes for the same message, and why does SCAN_RESP always contain Manufacturer Specific Data; Why is there such a big difference, and what changes has iOS 26 made for broadcasting? Is it necessary to include Manufacturer Specific Data in the IOS 26 SCAN.RESP message? What documents are available for reference? Is there any way to ensure that the local name is not truncated? Is there a maximum length limit Are there other ways to broadcast longer data? Does anyone know why? thank

After upgrading to iOS system 26, the local name broadcast type is 08, but before upgrading, it is 09 and will be included in the scan resp message; In version 26, the scan resp will also include Manufacturer Specific Data. Before the upgrade, the broadcast message may not necessarily include Manufacturer Specific Data; What I want to ask is, are there any restrictions on Bluetooth broadcasting in version 26? Is it necessary to include Manufacturer Specific Data data? If Manufacturer Specific Data data is included, it may cause fields in the local name broadcast to be truncated and use simple names of type 08

We have developed a live iOS application, built using Swift and UIKit, that enables users to connect via Bluetooth to an EV charging box. Once connected, users can start and stop the charging process directly from the app. The app also requires an active internet connection initially, as it uses server-side functionality to select and authorize the charging box. However, we recently discovered an issue affecting users on iPhone 14 and iPhone 15 models, specifically when the device enters Satellite mode (Emergency SOS via Satellite) — i.e., when there is no mobile data or Wi-Fi. In this mode, the system Satellite screen is triggered and Bluetooth stops functioning, preventing our app from connecting to the EV box. Users are unable to proceed, even though the app would still be usable via Bluetooth once the box is selected. We have already declared required Bluetooth background modes (bluetooth-central, bluetooth-peripheral) in Info.plist, and the app functions perfectly outside of this scenario. However, the behavior in Satellite mode appears to either disable Bluetooth entirely or restrict access from third-party apps. We’d like to know Is this the expected default behavior on iOS in Satellite mode? Is there any entitlement or exception available to allow Bluetooth access in such emergency scenarios (especially for critical utilities like EV charging)? Can an app like ours be made visible under the Satellite settings, or request access under this mode? This is a concern for users in remote or basement locations where mobile data is unavailable, and they rely solely on Bluetooth to charge their vehicles. Please advise if there is a workaround or planned support in future iOS versions. Thank you.