Overview We are developing a BLE + UWB accessory. We need to initiate UWB ranging as quickly as possible after establishing a BLE connection with an iPhone. However, it consistently takes approximately 900–1000 ms from centralManager(_:didConnect:) until the notification subscription (setNotifyValue) reaches the accessory. Most of this delay does not appear to be caused by ATT throughput or accessory response times, but rather by internal iOS processing. Details (Observed Behavior and Measurements) We tested this by implementing code on the app side to delay calling discoverServices by 1 second, measuring the processing times for both scenarios (with vs. without delay). Elapsed time for each phase measured on the app side (CBPeripheralDelegate): Phase Calling discoverServices immediately after connection Delaying discoverServices by 1 second didConnect → discoverServices call 0.1 ms (1000 ms delay) discoverServices → didDiscoverServices 416 ms 26 ms didDiscoverServices → didDiscoverCharacteristics 90 ms 60 ms Key Observations: The most notable finding is that simply delaying the discoverServices call by 1 second reduces the discoverServices → didDiscoverServices duration from 416 ms to 26 ms. This suggests that iOS is performing some internal processing right after connection, during which ATT service discovery responses appear to be delayed/postponed. Pure ATT discovery (Services + Characteristics) completes in about 86 ms when delayed. The app calls setNotifyValue(true, for:) immediately without delay inside peripheral(_:didDiscoverCharacteristicsFor:error:). However, the accessory receives the CCCD write approximately 400 ms after discovery completes. (Note: This 400 ms is an estimate based on the difference with accessory-side measurements). On the accessory side, completion of the ATT MTU exchange was observed around 380 ms after connection. Hypothesis We hypothesize that during the "first ~1 second after connection," iOS is sequentially executing link-layer control procedures (e.g., Feature Exchange, Version Exchange, Data Length Update, PHY Update) as well as ATT MTU exchange. Because these procedures are processed sequentially, ATT service discovery responses may be deprioritized or queued behind them. We have isolated the issue on the accessory side: the peripheral responds immediately to all requests, confirming that accessory processing delays or ATT throughput limitations are not the cause. Questions Is taking several hundred milliseconds to ~1 second from connection establishment (didConnect) to the completion of service discovery and notification subscription expected behavior in iOS? Is our understanding correct that iOS (CoreBluetooth / Bluetooth Controller) is executing link-layer control procedures during this initial period? If not, what specifically is taking place? Are there any means to shorten this duration from the app side or via peripheral connection parameters? Given the significant difference in response time between calling discoverServices immediately vs. delaying it, is there any way to prioritize ATT traffic right after connection or accelerate these procedures? For accessories that need to begin ranging immediately after connecting, what are the recommended best practices to minimize latency before data communication can start?

Hello, I am currently working with the Nearby Interaction framework on iOS and exploring the capabilities of UWB-based communication. I would like to ask whether Nearby Interaction supports multicast communication over UWB. Specifically, is it possible for one device to interact simultaneously with multiple peer devices using UWB (e.g., broadcasting ranging or spatial information to multiple devices at once), or is the framework strictly limited to one-to-one peer interactions? If multicast is not supported, are there any recommended approaches or best practices for achieving similar functionality using the current APIs? Thank you for your help. Best regards,