Hello, dear Apple engineers. We have recently tried to pair our Android phones and iPhones via BLE SMP, but have encountered a very high probability of pairing failures. Through PacketLogger and Android phone HCI, we have determined that the issue is caused by the iOS side sending an SMP Pairing Failed message during the SMP process. Please help us analyze the reason for this.

iOS currently restricts background Bluetooth advertising and scanning in order to preserve battery life and protect user privacy. While these restrictions serve important purposes, they also limit legitimate use cases where users have explicitly opted in to proximity-based experiences. The core challenge is that modern social applications need a way to detect when users are physically present at the same location or event without requiring every participant to keep their app in the foreground. Under the current system, background BLE advertising is heavily throttled and can only transmit a limited payload, background scanning intervals are sparse and unpredictable, peer-to-peer proximity detection cannot be maintained reliably when apps are in the background, and Background App Refresh is non-deterministic, making any kind of time-based proximity validation impossible. A proposed enhancement would be to introduce an “Enhanced Proximity Permission.” This would allow developers to enable reliable background BLE advertising and scanning for declared time windows, such as a maximum of eight hours. It would also allow devices running the same app to detect each other’s proximity using ephemeral, rotating identifiers that preserve privacy, with clear user consent and prominent indicators whenever the feature is active. Unlocking this capability would open up new categories of applications. Live events could offer automatic attendance tracking at concerts, conferences, or sports venues. Retail environments could support opt-in foot traffic analysis and dwell-time insights. Social apps could allow users to find friends at festivals, campuses, or other large venues. Safety applications could extend to crowd density monitoring and contact tracing beyond COVID-era needs. Gaming could offer real-world multiplayer experiences based on physical proximity, and transportation providers could verify rideshare pickups or measure public transit flows automatically. Privacy safeguards would remain central. Permissions would be time-boxed and expire after an event or session. A mandatory visual indicator would be displayed whenever proximity tracking is active. A user-facing dashboard would show all apps granted enhanced proximity access. Permissions would automatically be revoked after a period of non-use, and only ephemeral tokens not permanent identifiers would be broadcast. The industry impact would be significant. With this enhancement, iOS could power the next generation of location-aware social platforms while maintaining Apple’s leadership in privacy through explicit user control and transparency. Current alternatives, such as requiring users to keep apps in the foreground or deploying dedicated hardware beacons, produce poor user experiences and constrain innovation in spatial computing and social applications. Can anyone from Apple consider this change? Having to buy iBeacons is brutal and means slower adoption. Please reconsider this for users who opt in.

We are working with earphones that support Bluetooth BR/EDR (non-BLE). In our iOS app using CoreBluetooth, BLE peripherals appear during discovery, but this device does not.

Hello everyone, I’m developing an app that connects to Bluetooth Low Energy devices. While the stability of my connection is generally good, I’m looking to improve it. I noticed that the app from VanMoof, a company that makes ebikes, has an really strong connection. It even manages to connect to devices even when the app is forcefully closed. Could you please advise me on how I can improve the stability of my Bluetooth Low Energy connection and ensure that it continues to work even when the app is forcefully closed? Thanks in advance for your help!

We are testing BLE connectivity between a custom device (nRF52832, nRF5 SDK) and the latest iPad A16. Setup: Peripheral: nRF52832 running Nordic’s SoftDevice (nRF5 SDK v13) . Central: iPad A16 (Latest iPadOS 18.6.2). Issue: During the connection procedure, the iPad sends a Link Layer Control PDU with Opcode 0xFF. This is a vendor-specific LL control opcode. Our peripheral does not respond, since the Nordic SoftDevice does not implement handling for 0xFF. As a result, the link stability is affected (connection may drop / negotiation fails). Observations: With older iPads and iPhones (A14/A15 chips), no such control opcode is sent — connection and notifications work fine. Only the iPad A16 sends this vendor-specific opcode. Nordic’s SoftDevice responds to standard LL control opcodes, but ignores vendor-specific ones. Questions: Is this 0xFF LL control PDU expected behavior on A16 devices? Should peripherals ignore vendor-specific LL opcodes, or is a response required for stable connection? Are there known changes in BLE Link Layer negotiation with iPad A16?

Hi, Apple recently announced DL-TDoA (Downlink TDoA) support on iOS26. This API is currently marked as Beta. We are working on integrating this functionality into our app, already added the APIs and tried to configure a new DL-TDoA session using NIDLTDOAConfiguration (the only parameter it takes is networkIdentifer). The session is configured but automatically invalidated by the OS. When is DL-TDoA expected to be fully supported by phones? Can we expect a detailed documentation or specification explaining how to arrange the session with the DT-Anchors (channel, ranging duration, ...)? Do we need Bluetooth LE connection with the anchors while running DL-TDoA? We already have the 4 DT-Anchors (1 initiator and 3 responders) ready, looking forward to be able to test this new exciting feature and get DL-TDoA measurements to trilaterate the phone position within a map. Regards.

Hello fellow developers, I’m currently working on an app for controlling electric vehicle charging stations, and I’ve encountered some issues related to Bluetooth file transfer that I hope you can help with. For the OTA (Over-the-Air) update feature in this app, we need to transfer files via Bluetooth. These files are in .bin format and range in size from 1MB to 10MB. I’ve heard that Classic Bluetooth on iOS requires certification to use—is this true? If so, what are the general processes and requirements for this certification? Additionally, when considering BLE (Bluetooth Low Energy) for this purpose, we face challenges with transfer speed as well as file fragmentation and reassembly. Are there any optimization strategies for transferring large files over BLE that can improve speed while ensuring the integrity and accuracy of file fragmentation and reassembly? Finally, I’m wondering if there are any Bluetooth file transfer-related demos available for reference, especially sample code for iOS that handles file sizes and formats similar to what I described. This would be extremely helpful for resolving my current issues. Thank you very much for taking the time to read my questions. I look forward to your valuable advice and experience sharing.

We plan to use signals emitted from iBeacon to perform region detection in an app currently under development. We would like to know if region detection (didEnterRegion) can be performed when the app is in certain states. Region detection must be performed reliably. Is it possible to perform region detection in all of the following situations? • When the app is in the foreground • When the app is in the background • When the app is force-closed • When the smartphone is in sleep mode • When the smartphone is restarted Translated with DeepL.com (free version)

I'm trying to scan for Beacon's in a visionos app iBeacon detection via CoreLocation (like CLBeacon or CLBeaconRegion) isn't supported on visionOS, so I went for CoreBluetooth + Manual Beacon Parsing Problem is I don't get my beacons scanned, only the other bluetooth devices central.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey:true]) what should I do?

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?

I am working on an app that requires the usage of CoreBluetooth – using both its CBPeripheralManager and CBCentralManager classes. Our app works with other phones and hardware peripherals to exchange data – so we wanted to explore adding AccessorySetupKit to streamline the hardware connection process. AccessorySetupKit has been integrated (while CBPeripheralManager is turned off) and works great, but even with ASK added to our app's plist file and not in use, CBPeripheralManager fails with error: Cannot create a CBPeripheralManager while using AccessorySetupKit framework. Is there any workaround or suggested path forward here? We'd still really like to use ASK while keeping our existing functionality, but are not seeing a clear way to do so.

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!

We have iOS application to connect and monitor the Wiser smart devices. This application supports WiFi access point change as well. When there is change in the WiFi, wiser devices supports for 3mins BLE mode for re-pairing. When BLE devices are newly commissioning, all devices are being able to discover by CoreBluetooth. But when we try to change the WiFi, Previously connected BLE devices are not being discoverable though they are in pairing mode.

I have created a simple app that enters and exits an immersive space. I have not changed the basic code that gets created when you start a new visionOS project. I have connected a Magic Mouse to the AVP using BT. I have added a simple call to print(GCMouse.mice())and I have also tried print(GCController.controllers()) when the RealityView is launched inside the body closure. If I do not have the GCMouse/GCController call, everything works fine. However, with this perfect storm (Magic Mouse connected, enter immersive space, call GCMouse/GCController, exit immersive space) the onDisappear closure is never called, so I cannot reset my ToggleImmersiveSpace button out of disabled state due to transition. Once I power off and disconnect the mouse, the onDisappear closure is finally called. I have attempted to profile the issue, and I see that right before the onDisappear is called after the controllers are disconnected (which is long after the dismissImmersiveSpace was called), I see two mentions of some deallocation/destruction of GameController: -[GCMouse.cxx_destruct] -[GCPhysicalInputProfile(Pooling) release]

I want to fully control the BLE send timing myself, instead of relying on the iOS system. When I try to send a large data block using BLE (i.e., splitting it and sending multiple times), I follow Apple’s official guide. However, after the first successful updateValue() call in my loop, the second call always fails unless I wait for the peripheralManagerIsReady(toUpdateSubscribers:) callback. This callback timing is managed by the system, so I can’t control exactly when I can send the next packet. If I send data manually by clicking a button, updateValue() always returns true—even if I add a long delay (like sleep(10)) between calls. But in a loop, after the first send, updateValue() returns false until the thread leaves or the callback occurs. I suspect this is a thread or queue issue blocking subsequent sends. I also tried using DispatchQueue.global().async {} in the loop, but the result is the same. Is there any way to fully control when I call updateValue(), without waiting for peripheralManagerIsReady()? Or is this a limitation of iOS BLE? Thank you!

Im working on ios application that works with BLE device. The device uses BLE indications to provide data to the app. The goal is to achieve 100% data retrieval. According to the hardware team device behaves like this: CCCD Persistence: Device maintains Client Characteristic Configuration Descriptor (CCCD) with indication-enabled state across reconnections Resume Point: Device resends indications starting from the last unacknowledged indication before disconnection No Custom Logic: Follows standard BLE specification for indication reliability So it is expected that the device restores the indication streams from the last acknowledged one. My connection routine is: Discover services func centralManager(_ central: CBCentralManager, didConnect peripheral: CBPeripheral) { connectedPeripherals[peripheral.identifier] = peripheral peripheral.delegate = self updatePeripheralState(peripheral.identifier, to: .connected) print("Starting service discovery...") peripheral.discoverServices(nil) } Discover characteristics: func peripheral(_ peripheral: CBPeripheral, didDiscoverCharacteristicsFor service: CBService, error: Error?) { if let error = error { print("Characteristic discovery failed for service \(service.uuid): \(error.localizedDescription)") return } guard let characteristics = service.characteristics else { return } for characteristic in characteristics { if service.uuid == targetServiceUUID && characteristic.uuid == targetCharacteristicUUID { print("Found target characteristic! Enabling indications...") peripheral.setNotifyValue(true, for: characteristic) print(characteristic.properties.description) } } } Then the data retrieval: func peripheral(_ peripheral: CBPeripheral, didUpdateValueFor characteristic: CBCharacteristic, error: Error?) { if let error = error { print("Error reading characteristic value: \(error.localizedDescription)") return } if characteristic.service?.uuid == targetServiceUUID && characteristic.uuid == targetCharacteristicUUID { if let data = characteristic.value { let formatter = DateFormatter() formatter.timeStyle = .medium formatter.dateStyle = .none // data filtering since device is sending some other events sometims if data.count >= 15 { let event = decodeBytes(bytes: data) let now = Date() let timestamp = timestampFormatter.string(from: now) print("[\(timestamp)] Auto Increment: \(event.autoIncrement) Type: \(event.type)") } } else { print("Received indication with no data") } } } Using PacketLogger from xcode toolbox i have confirmed that: The device starts sending indications right after didConnect finishes The phone is sending ACKS for those indications Indications are not reaching didUpdateValueFor until peripheral.setNotifyValue(true, for: characteristic) properly executes This mekes me drop some data data on each reconnect. I already know I can do better in terms of service and characteristics discovery: I should discover only that one which is giving me the indications. But my intuition is: discover only the service and characteristic i care about will minimize the impact, but not guarantee 100% data retrieval Is this expected and confirmed CoreBluetooth behavior?

Hi, I've seen the documents that Apple Technical Q&A QA1931 said: Note: If Bluetooth Low Energy HID is one of the connected services of an accessory, connection interval down to 11.25 ms may be accepted by the Apple product. But in real world, is there any "iOS device" connection interval down to 11.25 CI that is accepted?

Does the iPhone or iPad support reception of the following communication standards? If so, please let me know if there is an swift API available. ・Bluetooth 5.x Long Range ・Wi-Fi Neighbor Awareness Networking (Wi-Fi Aware) ・Wi-Fi Beacon

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.

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