Our app is using the CLLocationManager to wake up the app near an iBeacon and then tries to connect to the accessory via bluetooth and UWB. For this to work in the background we need to create a Live Activity and show the user that the app is doing something. When the app is in the foreground or just recently got into the inactivity mode this works fine and we can use CoreBluetooth/NearbyInteraction even when the app then enters the background mode. But when the app is longer in the background creating a Live Activity via Activity.request() throws an ActivityAuthorizationError.visibility. According to the documentation the LiveActivityIntent is able to workaround this background restriction but I get the same exception when I create the LiveActivity from the perform() method. Is there another API to create Live Activities? Do I need to prepare the LiveActivityIntent somehow?

Situation: We have an app that only uses location UIBackgroundModes key to restart our app on significant change events as we need it to connect with a BLE device (mounted in the car) when someone starts driving. We cannot use geofence as the car might be used by multiple people so position changes and we don't want to store locations and sent them to multiple users via our servers. So currently we use significant change and just ignore all other location data. During app review we got the following feedback: If the app does not require persistent real-time location updates, please remove the "location" setting from the UIBackgroundModes key. You may wish to use the significant-change location service or the region monitoring location service if persistent real-time location updates are not required for the app features. Question: How to use the significant-change location service without the "location" setting from the UIBackgroundModes key or is there any other way to start the app / connect with the BLE device when it is fully terminated/swiped away? Because the docs state that AuthorizationStatusAuthorizedAlways is required and without the UIBackgroundModes key location that wouldn't be triggered when app is in the background/swiped away. Reference: https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html#//apple_ref/doc/uid/TP40009497-CH2-SW8

Good morning, Apple devs. I'm looking for resources and help designing a BLE hardware peripheral that is compatible with iOS and iPad. I've seen the MFi program, but I've also seen plenty of peripheral devices that work with iOS and iPad that are not listed in the MFi compatibility lists. Can anyone refer me to the proper channels to get support for development of a hardware device? Thank you.

The same code built in a regular Mac app (with UI) does get paired. The characteristic properties are [.read, .write, .notify, .notifyEncryptionRequired] The characteristic permissions are [.readEncryptionRequired, .writeEncryptionRequired] My service is primary. In the iOS app (central) I try to read the characteristic, but an error is reported: Error code: 5, Description: Authentication is insufficient.

Several of my users are reporting on at lest recent and current versions of iOS the value from one characteristic can be swapped with another. Originally I thought this was a library issue but it doesn't happen on Android and now a user with two iPhones using the exact same app and iOS 26.3 on both has the issue on one phone but not the other. I've gone into more detail here which also includes a little data dumping to prove the values between characteristics can be mixed up. https://github.com/dotintent/react-native-ble-plx/issues/1316 One user reported cycling Bluetooth on/off fixed the issue but the latest user says it does not. For the peripheral the services can only change if the device enters firmware update mode (in which case the service UUID is different). Otherwise the characteristics on a service never change. This would make it a strange one to be caching related since the cache should always be correct.

https://developer.apple.com/feedback-assistant/profiles-and-logs/ There is no iOS profile in this link.

We are observing a reproducible issue on some (not all) iPad models equipped with A16, where BLE streaming from multiple peripherals at ≥33–40 Hz results in uneven packet distribution, burst delivery, and application-level lag. The same application, peripherals, firmware, iOS version, and physical environment do not exhibit this behaviour on A14-based iPads (iPad 10). Affected Hardware: • iPad 11" with A16 • iOS versions: identical across tested devices • Issue affects some devices of the same model, not all Internal field data • ~25 affected • ~5 unaffected • Customers actively prefer iPad 10 (A14) due to stability When two or more BLE peripherals stream data concurrently at frequencies ≥33–40 Hz, affected iPads exhibit: • Uneven packet arrival timing • Burst delivery instead of uniform intervals • Increasing latency over time • Observable application-level lag This does not present as simple packet loss. Instead, packets arrive in clusters, breaking real-time assumptions. At ≤30–33 Hz, the issue does not reproduce. We tested: • One affected iPad 11 • One unaffected iPad 11 • Same iOS version • Same app build • Same peripherals • Same firmware • Same physical location • Same Wi-Fi state Only the affected device reproduces the issue. This rules out: • App logic • Peripheral firmware • iOS version • Environmental RF noise • Wi-Fi coexistence configuration Evidence Available We can provide: • Screenshots from a minimal test app showing packet counts • CSV files of packet timestamps • Source code for the BLE test app • Side-by-side comparison logs (affected vs unaffected device) All evidence is from the same app, built solely to measure packet timing. Additional Technical Notes • Issue persists after factory reset • Occurs without third-party BLE libraries (CoreBluetooth only) • Occurs regardless of foreground/background state • Not correlated with MTU size • Appears threshold-based (~33–40 Hz) • Appears device-specific, not model-wide

Right now, I am scanning for specific BLE peripherals with my iPad app, using this: [self.cbCentralManager scanForPeripheralsWithServices:serviceUUIDsToScanFor options:@{CBCentralManagerScanOptionAllowDuplicatesKey:@YES}]; I have the "CBCentralManagerScanOptionAllowDuplicatesKey" set true because I need to be able to detect when a peripheral is no longer advertising, so I capture each "didDiscoverPeripheral" callback and set a 3-second timer that notifies the user that that peripheral is no longer in range if another didDiscoverPeripheral hasn't been received in that time. The peripherals all advertise at 100ms intervals. What's weird is that if I leave the scan on for a long time, the advertising packets slow down, and eventually one of those timers times out, around about one or two minutes for the first instance, and then every 10-20 seconds after that. I've checked with ATS for all the BLE traffic, and there are indeed > 3-second gaps in the advertising packets that the iPad sees, so it's not my code introducing the gap. Is there some reason long-running scans should not be done on iPadOS (both 18 and 26.1 used)? I've tested out switching my scan to "stopScan" and restart it every 10 seconds, and that seems to have resolved the issue, but it's unclear why that would matter (and that does not seem like an appropriate use of the stop and start scans). Thanks!

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?

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.

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

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.

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.

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?

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!

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?

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

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

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.)

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?