My team has an app that uses BTLE heavily, and has been doing so successfully, including no issues continuing to receive data in the background and updating things in the app (for recording workouts). We have a BTLE write queue that only tries to write when the CBPeripheral.canSendWriteWithoutResponse property is true, or when we get the notification from the system in peripheralIsReady(toSendWriteWithoutResponse:). This is used as a means to rate limit data transfer, as we transfer files, as well as require that packets always arrive in the correct order due to blob encoding. However, we had a new requirement come in to periodically write data out to a connected peripheral. I noticed that as soon as the app was in the background, despite other delegate callbacks coming in, like didRecieveUpdatedValue:, neither the property canSendWriteWithoutResponse nor the delegate callback were called any longer. This meant our write queue didn't think it had permission to write, and packets would just stack up. The failure to deliver these updates didn't occur immediately after backgrounding, but did within 2-5s of backgrounding. If, when in the background, I ignore the changing of that property, and instead just write the data to the peripheral, it works! Can anyone explain why, despite other CBPeripheral callbacks happening when in the background, this one does not?

After the macOS Sequoia update, my app seems to have an issue with Bluetooth communication between macOS and iOS that uses CoreBluetooth for Central-Peripheral communication. Setup: The iPhone (in my case: iPhone 14 Pro with iOS 18.0 (22A3354)) acts as the Central, and the Mac (in my case: 14" MacBook Pro 2023 with macOS 15.0 (24A335)) as the Peripheral. I’ve implemented a mechanism where the Central (iPhone) sends a message to the Peripheral (Mac) every 15 seconds to keep the connection alive (Because it needs to wait for notify characteristic updates). I never noticed this kind of issue before, but with macOS Sequoia I get it permanently. Issue: The connection drops unexpectedly after a period of time (sometimes 20 seconds, sometimes a few minutes) with CBErrorDomain - code 6: The connection has timed out unexpectedly. Sample Code: Peripheral (Mac): ContentView (Peripheral).txt ContentViewModel (Peripheral).txt Central (iPhone): ContentView (Central).txt ContentViewModel (Central).txt Reproduce: I attached sample code including the Central-Sample (for iPhone) and Peripheral-Sample (for Mac). Just run the Peripheral-Sample (after granting Bluetooth permissions). Then run the Central-Sample and select the Mac device in the list After selecting it should connect, discover the service & characteristic and should start writing messages to it. After some time the func centralManager(_ central: CBCentralManager, didDisconnectPeripheral peripheral: CBPeripheral, error: (any Error)?) {should get called with timed out unexpectedly error. Could anyone please look into this issue and advise on whether there’s a known bug or any workaround? Any guidance would be greatly appreciated, as this impacts the stability of Bluetooth communication between the devices. Thanks in advance. Logs: I also ran the console.app during this issue which got these errors (if this is helpful): console_logs.txt

I am learning about endpoint security and other system extensions, while I was handling ES_EVENT_TYPE_AUTH_IOKIT_OPEN event I realized that I cannot auth deny any bluetooth events. I tried to deny any open or execute events related to com.apple.bluetoothd but it did not work. I searched google and found out that I can use CoreBluetooth to control bluetooth. But when I get connected to bluetooth keyboard or mouse, didConnectPeripheral dose not get called or when I call [central cancelPeripheralConnection:peripheral] disconnection never happens. Is there any recommendation for handling or controlling events related to bluetooth connection?

My watch APP needs to keep Bluetooth connected with peripherals whether it is in the foreground or background, but the results of my test show that the connection in the background is very unstable, sometimes you can keep the Bluetooth on for a day, but sometimes it will be disconnected 50 times a day, and every time it is disconnected, I will immediately initiate a reconnection, it is certain that there is no problem with the peripheral Bluetooth, because I have another iOS device that has been stably connected to the peripheral, I want to know what causes this instability, and if there is any solution, if someone can provide relevant advice, I will be very grateful

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

When I startAdvertising, my localName is long, more than 8 bytes. like @"123456789".    [_peripheralManager startAdvertising:@{             CBAdvertisementDataLocalNameKey: @"123456789",             CBAdvertisementDataServiceUUIDsKey: @[[CBUUID UUIDWithString:@"bbbb14c7-4697-aaaa-b436-d47e3d4ed187"]]             }]; When running on macOS 11.x though localName exceeds 8 bytes. But it can still be scanned. {   kCBAdvDataIsConnectable = 1;   kCBAdvDataLocalName = 123456789;   kCBAdvDataRxPrimaryPHY = 0;   kCBAdvDataRxSecondaryPHY = 0;   kCBAdvDataServiceUUIDs =   (     "BBBB14C7-4697-AAAA-B436-D47E3D4ED187"   );   kCBAdvDataTimestamp = "680712553.800874";   kCBAdvDataTxPowerLevel = 12; } But running after macOS 12.x, if localName exceeds 8 bytes, it will be completely ignored. In the scanned data, localName is empty. {   kCBAdvDataIsConnectable = 1;   kCBAdvDataRxPrimaryPHY = 0;   kCBAdvDataRxSecondaryPHY = 0;   kCBAdvDataServiceUUIDs =   (     "BBBB14C7-4697-AAAA-B436-D47E3D4ED187"   );   kCBAdvDataTimestamp = "680712744.108894";   kCBAdvDataTxPowerLevel = 12; } On macOS11.x, SCAN_RSP is utilized if localName exceeds 8 bytes, while on macOS12.x, SCAN_RSP is always empty. Why are there differences between macOS11.x and macos12.x, is there any documentation? What is the maximum limit for localName? (On macOS 11.x, I verified it was 29 bytes Are there other ways to broadcast longer data? Does anyone know why? This has bothered me for a long time...

Since WatchOS 8.0.1 CoreBluetooth drops an active connection if the App goes to background (or back to foreground). This can be reproduced easily with this sample code: Interacting with Bluetooth Peripherals During Background App Refresh If you run the app on the Apple Watch and turn your wrist, an active connection is terminated. In the output window you can read: 2021-10-20 20:22:41.210839+0200 BARBluetooth WatchKit Extension[382:94603] [BluetoothReceiver] disconnected from Sender. The same is the case with my other Watch Apps, that are connecting to BLE devices. As far as I remember, with WatchOS 8.0 everything was fine. Since this occurs even on WWDC21 sample code this must be a bug. Is there a way to fix it for myself, or do I have to wait until it gets fixed by Apple?

How does core bluetooth work on tvOS? Is it available for use? Any docs would be helpful?

I am pretty sure iOS 13.4 (beta and later) did support Coded PHY (Long Range). Tested devices are iPhone SE2 and iPhone 11 Pro. However, it seems iOS 14 removed the support of Coded PHY, accidentally or on purpose, I don't know? The same PHY update request returns "1M PHY" in iOS 14, but "Coded PHY" in iOS 13 (13.4 beta and later). Anyone knows why? Samson

Hello All,I am trying to communicate with BLE device which is using HID service through my iOS App using Core Bluetooth.While discovering all Services , i cannot look HID Service but i can look other services. As per previous versions , Core Bluetooth doesn't expose HID peripheral service capabilities to apps.Currently i am using Xcode 8 and iOS 10 version for development. Is there any update on exposing HID peripheral service in latest versions. If yes, how can i achive this?I will appreciate any help!!

Greetings.I have an app today that uses multipeer connectivity extensively. Currently, when the user switches away from the app, MPC disconnects the session(s) - this is by design apparently (per other feedback). I'd like to hear if anyone has experimented with iOS9 multitasking / multipeer and whether MPC sessions can stay alive?Thanks