Technical Inquiry about CoreBluetooth Scanning & NEHotspotConfigurationManager Workflow

I am writing to seek clarification on two technical issues related to iOS frameworks (CoreBluetooth and NetworkExtension). These observations are critical for optimizing our app's performance, and I would appreciate any official guidance or documentation references.

  1. CoreBluetooth Scanning Frequency and Cycle

Issue: We noticed inconsistent BLE device discovery times (ranging from 0.5s to 1.5s) despite the peripheral advertising at 2Hz (500ms interval).

Questions:

Does iOS regulate the BLE scan interval or duty cycle internally? If yes, what factors affect this behavior (e.g., foreground/background state, connected devices)? Are there recommended practices to reduce discovery latency for peripherals with fixed advertising intervals? Is there a way to configure scan parameters (e.g., scan window/interval) programmatically, similar to Android's BluetoothLeScanner? Test Context:

Device: iPhone 13 mini (iOS 17.6.1) Code: CBCentralManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true])

  1. NEHotspotConfigurationManager Workflow and Latency

Issue: Using NEHotspotConfigurationManager.shared.apply(_:) to connect to Wi-Fi occasionally takes up to 8 seconds to complete. Questions:

What is the internal workflow of the apply method? Does it include user permission checks, SSID scanning, authentication, or IP assignment steps? Are there known scenarios where this method would block for extended periods (e.g., waiting for user interaction, network timeouts)? Is the latency related to system-level retries or radio coexistence with other wireless activities (e.g., Bluetooth)? Test Context:

Configuration: NEHotspotConfiguration(ssid: "TestSSID") Behavior: Delay occurs even when the Wi-Fi network is in range and credentials are correct.

Answered by DTS Engineer in 829029022

I’m gonna respond to your NEHotspotConfigurationManager question here. I don’t know enough about Bluetooth to answer your other question. I recommend that you put that question in a new thread. Put it in App & System Services > Core OS and tag it with Core Bluetooth. That’ll increase the chances of it being seen by folks with Bluetooth experience.

Regarding NEHotspotConfigurationManager:

Written by Wise-Lee in 776432021
Are there known scenarios where this method would block for extended periods … ?

What do you mean by “block”?

The apply(_:) method is asynchronous. You call it and then, at some point in the future, it calls the completion handler. Given that, there are two potential interpretations of the work “block”:

  • The apply(_:) method takes a long time to return.

  • The apply(_:) returns quickly but there’s a long delay before it calls the completion handler.

The first would be most unusual. If you see that, it’s definitely bugworthy.

The second is expected. This operation can prompt the user for permission to join the Wi-Fi network, which means that there can be an unbounded delay waiting for the user to reply.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I’m gonna respond to your NEHotspotConfigurationManager question here. I don’t know enough about Bluetooth to answer your other question. I recommend that you put that question in a new thread. Put it in App & System Services > Core OS and tag it with Core Bluetooth. That’ll increase the chances of it being seen by folks with Bluetooth experience.

Regarding NEHotspotConfigurationManager:

Written by Wise-Lee in 776432021
Are there known scenarios where this method would block for extended periods … ?

What do you mean by “block”?

The apply(_:) method is asynchronous. You call it and then, at some point in the future, it calls the completion handler. Given that, there are two potential interpretations of the work “block”:

  • The apply(_:) method takes a long time to return.

  • The apply(_:) returns quickly but there’s a long delay before it calls the completion handler.

The first would be most unusual. If you see that, it’s definitely bugworthy.

The second is expected. This operation can prompt the user for permission to join the Wi-Fi network, which means that there can be an unbounded delay waiting for the user to reply.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Technical Inquiry about CoreBluetooth Scanning & NEHotspotConfigurationManager Workflow
 
 
Q