Using an iPhone Pro 12 running iOS 26.0.1, with AirPods Pro 3. Camera app does capture video with what seems to be "Studio Quality Recording". Am trying to replicate that SQR with my own Camera like app, and while I can pull audio in from the APP3 mic, and my video capture app is recording a 48,000Hz high-bitrate video, the audio still sounds non-SQR. I'm seeing bluetoothA2DP , bluetoothLE , bluetoothHFP as portType, and not sure if SQR depends on one of those? Is there sample code demonstrating a SQR capture? Nevermind video and camera, just audio even? Also, I don't understand what SQR is doing between the APP3 and the iPhone. What codec is that? What bitrate is that? If I capture video using Capture and inspect the audio stream I see mono 74.14 kbit/s MPEG-4 AAC, 48000 Hz. But I assume that's been recompressed and not really giving me any insight into the APP3 H2 transmission?

Recently, I've noticed that background Bluetooth scanning stops when I move an app to the background on an iPhone 17 device with Bluetooth 6. I'm curious about a solution. Background Bluetooth scanning doesn't stop on devices older than iOS 26, or on devices that were updated from an iPhone 17 or earlier to iOS 26.

PLATFORM AND VERSION Model - iPhone 13 Pro Max (Potentially for other models also) OS - iOS 26 DESCRIPTION OF PROBLEM : BLE discoverability (advertising) is not working on iOS 26 but works reliably on older iOS versions. Details: Our app acts as a Bluetooth peripheral. When advertising, the app only adds CBAdvertisementDataLocalNameKey in advertisement data. Format of local name - "NTDI:103202400001" We have observed that in iOS 26, the local name is getting truncated. This breaks the parsing logic in our IOT device central code, which expects the full local name to be present. We have also observed that some extra data is getting added to the advertisement data by the OS. As of now, updating the IOT device logic for parsing is not possible. STEPS TO REPRODUCE Create an instance of CBPeripheralManager. Start advertising with a local name with the format "NTDI:103202400001" Capture the advertisement data using a Bluetooth sniffer tool. Observe that the local name is getting truncated Legacy ADV_IND as received by IoT device (truncated name): HCI Event: LE Meta Event (0x3e) plen 27 LE Advertising Report (0x02) Event type: ADV_IND (0x00) Data length: 15 Flags: 0x1a TX power: 12 dBm 12 09 4e 54 44 49 3a 31 30 ..NTDI:10 RSSI: -47 dBm Only partial Local Name (“NTDI:10…”) is present in this primary PDU. Is it possible to avoid the extra data introduced by iOS or avoid local name truncation?

Our app scans Bluetooth in the background. However, the iPhone 17 device does not scan in the background. ios 26 Is there anything I need to do?

Hello. Is there a solution to the issue where Core Bluetooth does not run in the background on the iPhone17? https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html The bluetooth-central Background Execution Mode When an app that implements the central role includes the UIBackgroundModes key with the bluetooth-central value in its Info.plist file, the Core Bluetooth framework allows your app to run in the background to perform certain Bluetooth-related tasks. While your app is in the background you can still discover and connect to peripherals, and explore and interact with peripheral data. In addition, the system wakes up your app when any of the CBCentralManagerDelegate or CBPeripheralDelegate delegate methods are invoked, allowing your app to handle important central role events, such as when a connection is established or torn down, when a peripheral sends updated characteristic values, and when a central manager’s state changes. Although you can perform many Bluetooth-related tasks while your app is in the background, keep in mind that scanning for peripherals while your app is in the background operates differently than when your app is in the foreground. In particular, when your app is scanning for device while in the background: The CBCentralManagerScanOptionAllowDuplicatesKey scan option key is ignored, and multiple discoveries of an advertising peripheral are coalesced into a single discovery event. If all apps that are scanning for peripherals are in the background, the interval at which your central device scans for advertising packets increases. As a result, it may take longer to discover an advertising peripheral. These changes help minimize radio usage and improve the battery life on your iOS device.

Recently, I've noticed that background Bluetooth scanning stops when I move an app to the background on an iPhone 17 device with Bluetooth 6. I'm curious about a solution. Background Bluetooth scanning doesn't stop on devices older than iOS 26, or on devices that were updated from an iPhone 17 or earlier to iOS 26.

Our app scans Bluetooth in the background. However, the iPhone 17 device does not scan in the background. ios 26 Is there anything I need to do? The setting values are as follows. device connection interval min : 60 connection interval max : 75 slave latency : 0 supervision timeout : 4000 advertising interval : 20

Our app scans Bluetooth in the background. However, the iPhone 17 device does not scan in the background. ios 26 Is there anything I need to do? device1 connection interval min : 60 connection interval max : 75 slave latency : 0 supervision timeout : 4000 advertising interval : 20

We are develop an application with corebluetooth framework. we connect to device with ble. and open two l2cap channels. it can transfer data with stream. but when it close the second l2cap channel, it always close the first l2cap channel.

Dear Apple Team,​ We are reaching out regarding several compatibility issues our app users have encountered after upgrading to iOS 26. These issues not only affect our application but also seem to impact the system's native settings, which has raised concerns about the universality of these problems.​ Problem Description​ Bluetooth Functionality: When users attempt to use the Bluetooth feature within our app after upgrading to iOS 26, the app freezes completely. What's more, when accessing the Bluetooth section in the system Settings app, it also freezes and ultimately crashes.​ Location Service: The location service on the device becomes inoperable after the iOS 26 upgrade. However, both the Bluetooth and location service issues are resolved after the user restarts the device.​ 2. Questions​ Universality: We are eager to know if these issues are exclusive to our app or are a more widespread problem among other applications on iOS 26. Are these known compatibility glitches in iOS 26? ​ Avoidance: Is there any guidance or best - practice that we, as developers, can follow to avoid these issues in our app? For example, are there specific API calls or configurations that need to be adjusted? ​ System - level Impact: If these are system - level bugs related to Bluetooth and location services, will they affect all apps that rely on these features? Or are there certain app - level mitigations that can be implemented? ​ We would greatly appreciate it if you could provide us with any insights, solutions, or information regarding these issues. Your prompt response will be crucial for us to address these problems and ensure a smooth user experience for our customers.​ Thank you in advance for your assistance.​ Best regards,

I am currently developing a BLE device that connects to iPhone and transmits a large amount of data within a certain period of time. The BLE device sends data to iPhone under the following conditions, but the transfer speed does not meet my expectations. Could you guys tell me how I can further increase the transfer speed. Conditions: iPhone14 Pro iOS 17.0 Connection Interval = 15ms More Data Flag = valid Characteristic sending = Notification

Environment: iOS Version: 26.0 Device Model: iPhone 12 Pro Max Peripheral: [Fill in peripheral name/model/firmware version] Steps to Reproduce: Connect to the peripheral using CoreBluetooth. Discover services via discoverServices. Discover characteristics via discoverCharacteristics. Call setNotifyValue:YES for a characteristic that supports notifications (Notify or Indicate). Capture the HCI log during the above process. Expected Result: After calling setNotifyValue:YES, CoreBluetooth should write the appropriate value to the Client Characteristic Configuration descriptor (UUID: 0xFCF8) to enable notifications, and subsequent notifications should be received from the peripheral. Actual Result: After calling setNotifyValue:YES, no subscription action is triggered. HCI logs show that the subscription write to the CCC descriptor (0xFCF8) is missing. The target service and characteristic values have already been discovered prior to calling setNotifyValue:YES. Additional Information: HCI log screenshot attached below highlights the moment after setNotifyValue:YES was invoked, showing no GATT Write Request to the CCC descriptor. Full HCI log file is also attached for reference. 11:29:38:165: Call setNotifyValue: YES

Hi Team, I’ve tried downloading the EnableBluetoothCentralMatterClientDeveloperMode.mobileconfig certificate from multiple sources, but all the links I found point to expired versions. Could you please help me with the URL to the latest version of this certificate? Here are the links I’ve already tried, but none of them worked: https://project-chip.github.io/connectedhomeip-doc/guides/darwin.html#profile-installation https://github.com/project-chip/connectedhomeip/blob/master/docs/guides/darwin.md Apple Site Looking forward to your support. Thanks, Mantosh Kumar

I work for a large medical device company. We have a 1st party BLE enabled medical device that must be very battery efficient. To this end, if a connection is lost, the BLE radio is powered down after 60 seconds and will only turn back on when a physical button on the device is pressed. I've been tasked with connecting to the device, staying connected to the device, and being able to retrieve data from the device upon a timed action. For instance, this could include a data read and transmission while they sleep. The key part of this is staying reliably connected for extended periods of time. This is a BYOD setup, and we cannot control power profiles. I would very much appreciate any information, recommendations, and/or insights into solving this problem. Thanks!

Hello world! Given some suitable byte sequences b1, b2 and a Bluetooth Low Energy device that provides two GATT characteristics c1 and c2, can I call CBPeripheral.writeValue(b1, c1) and then CBPeripheral.writeValue(b2, b2) without waiting for the callback of the corresponding CBPeripheralDelegate to occur for the first write operation to c1 and without causing one of both operations to fail due to iOS's BLE implementation? Is there any official documentation or specification that states what would or could happen in such scenario? The background of this question is that on Android, you usually can only perform one GATT operation on a single BluetoothGatt instance at a time. Consecutive operations, even for different characteristics, that do not await the callback invocations of previously requested GATT operations, usually just fail. However, experimenting with CBPeripheral, I can see that such accesses seem to be working on iOS. Now, is that undefined behavior and I am just observing a forgiving implementation or this actually specified behavior? I would be glad about any hints or comments on this matter that have foundation in the official Apple developer documentation or any official Bluetooth specification. Since I already tried my luck with search engines, I would assume that this is just undefined behavior. Thank you! Regards, Luis.

macOS15.6 Bluetooth status always returns CBManagerStateUnsupported

Apple recently announced DL-TDoA (Downlink TDoA) support on iOS 26, and the API is currently marked Beta. Using two iPhones (16 Pro and 13) on iOS 26.0 Beta, I’m starting a Nearby Interaction session and need to read NITLDOA parameters (address, carrier frequency offset, signal strength/RSSI), but I can’t find a supported way. I’m also seeing asymmetry: iPhone 13 reports distance+direction, while 16 Pro reports distance only. Is there a supported workflow/API to access those parameters, and any known device/OS constraints that would cause direction to be unavailable on 16 Pro?

Hi all, In InfiniTime, somebody finally implemented ANCS which forced iOS to encrypt the ble connection. As a result, my PineTime appears in the battery widget. Unfortunately, I only get a Bluetooth logo as the icon. Ideally it would be a smartwatch glyph. The GAP appearance value is being set to 0xC2 (smartwatch) Note: I've used CMF watches in the past, and they display with a smartwatch icon Any thoughts?

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.