[Bug]: QueueType global and perDevice degradation on Apple

[raphael-bmec-co]

Library version

2.1.0

Reproducible with the example app

Not tested

OS

macOS

OS version

macOS 26.5.1; iOS 26.5.2

Device connecting to

ESP32

BLE version of connecting device

No response

What happened?

I'm not sure if this is expected behaviour or a bug but when using QueueType.global or QueueType.perDevice on macOS, iOS or even chrome on mac we see successive messages take longer and longer so ~starting at 300us for 512 MTU and then growing by 50-100 ms per message until 1500 ms + eventually causing timeouts. We also cannot connect to more than one device at a time.

This does not occur on Windows/Android. Although Android shows issues with none and perDevice- which I believe is expected. Especially with multiple connections. Whereas on windows there is an issue with none.

Apologies in advance, this is challenging to produce sample code etc.

Perhaps this is just a documentation issue - in which case a table of what works where would be a nice addition? Perhaps there is a bug of sorts.

Dev env	App	none	global	perDevice
Windows	Android (physical device)	❌ 1	✅	❌ 1
Windows	Chrome	⚠️ 2	✅	⚠️ 2
Windows	Windows	❌ 1	✅	✅
Mac	Chrome	✅	❌ 3	❌ 3
Mac	macOS	✅	❌ 4	❌ 4
Mac	iOS (physical device)	✅	❌ 4	❌ 4

1. Cannot transmit to multiple devices.
2. Degraded throughput
3. Cannot connect to multiple devices
4. Performance (on at least one device) degrades with each transmission.

[rohitsangwan01]

Queue Type global and per device is suppose to wait for operations, seems like Mac takes time to complete, and if one of the operation stuck, then it will block whole queue unless timeout
Or do you think the operation completes but the queue still stuck and waits for the completion or timeout ?

[raphael-bmec-co]

I can't say 100% but I'm fairly certain there is some unexpected behaviour.

For example, why can you not make simultaneous connections in some cases?

Moreover, the operation time should not take longer for each successive message. Importantly, it still takes longer if you transmit, wait for completion, wait another few seconds and then do the next transmit.

For now we use the table we built to set the queue type by platform.

Just to add that we don't see any errors/logs coming from the underlying platform layers in and of the cases, so I don't think there is an exception firing at the platform layer.

[fotiDim]

@raphael-bmec-co can you please test on #272?

[raphael-bmec-co]

Issue persists on #272.

The test below sends a message in a stream to an (ESP32 which echos it back) and parses the result if/when it gets it back.

You can see how the RTT grows with each message. Interestingly I stopped transmission between 7 and 8 and waited a few seconds. You can see that the time still climbed.

For context. The same test with none gives a consistent RTT of <250 ms (depending on parameters) and even with 2 devices connected and running at the same time.

[fotiDim]

@raphael-bmec-co please try with #281

[heidi-bmec-co]

@fotiDim we tested with #281, only on mac. Slight improvement with the Chrome app on mac now working. Unfortunately the same issue still occurs with macOS and iOS apps.

Library version

fix/apple-write-queue-27

Reproducible with the example app

Not tested

OS

macOS

OS version

macOS 26.5.2; iOS 26.5.2

Devices connecting to

ESP32 x 2

What happened?

Dev env	App	none	global	perDevice
Mac	Chrome	✅	✅	✅
Mac	macOS	✅	❌ 4	❌ 4
Mac	iOS (physical device)	✅	❌ 4	❌ 4

1. Cannot transmit to multiple devices.
2. Degraded throughput
3. Cannot connect to multiple devices
4. Performance (on at least one device) degrades with each transmission.

Chrome on mac

MacOS

[fotiDim]

Thanks! The screenshots suggest a new message is scheduled every second even when the previous echo is still pending. Could you confirm:

• Is each write withResponse or withoutResponse?
• Does the stream await the previous UniversalBle.write() Future or echoed response before sending again, or does a periodic timer enqueue writes independently?

Sharing just the write/timer snippet would be enough.

[raphael-bmec-co]

@fotiDim

Just to let you know that we are not blocked by this issue (so you are not rushing for us) as we are using none on Apple now. But will support your efforts to resolve both for open source contribution and because having the option would be great (I also suspect it may not be working 100% on other platforms as per the table here: #271 (comment)).

To answer your questions:

a new message is scheduled every second even when the previous echo is still pending

Yes and no, we place a new message into our own queue (per device) every rate (second in this test). However, that queue is processed in series as detailed below.

Is each write withResponse or withoutResponse?

withResponse

Does the stream await the previous UniversalBle.write() Future or echoed response before sending again, or does a periodic timer enqueue writes independently?

It awaits the write() (per our queue/device) before sending again. It does not await the echo as there is a separate characteristic for RX and TX.

It is hard to share a code snippet as things are heavily abstracted on our side.

The following is called inside our subscription to our queue - so it blocks and awaits ( I have confirmed writeWithoutResponse = false):

for (final String packetJson in packetJsonStrings) {
  await _charRx.writeToBle(packetJson).timeout(timeOut);
}

  Future<void> writeToBle([T? value]) async {
    this.value = value ?? this.value;
    return ub.UniversalBle.write(_deviceId!, _serviceId!, _characteristicId!,
            Uint8List.fromList(valueToBytes()),
            withoutResponse: writeWithoutResponse)
        .then((_) => log.i(
            'Characteristic $name set ${writeWithoutResponse ? "(without response)" : ""}to ${this.value}.'))
        .onError((error, stackTrace) {
      log.e("Failed to write value ${value.toString()} to characteristic $name",
          error: error, stackTrace: stackTrace);
    });
  }

Finally, just to say that it may well be an interaction of our stack that is the root cause - although nothing obvious comes to mind. I'd expect the global and per device queues to be thread save - we aren't running any isolates here anyway so it is de-facto single threaded.

[fotiDim]

@raphael-bmec-co thanks, that’s helpful. One more test would help us narrow this down:

• Does the RTT still increase with QueueType.perDevice when only one device is connected and sending?
• Roughly how many packetJsonStrings are written for each 1× MTU message, and how large is each write?

Note that Dart’s .timeout() doesn’t cancel the BLE write underneath it. Could you stop the test at the first timeout, or temporarily remove that outer timeout? Otherwise, writes from after the timeout may overlap with ones that are still running.

[raphael-bmec-co]

@fotiDim

Does the RTT still increase with QueueType.perDevice when only one device is connected and sending?

We will test the single device case for you ASAP (just need to spin up the test stack to do so [@heidi-bmec-co]).

Roughly how many packetJsonStrings are written for each 1× MTU message, and how large is each write?

1 x MTU is typically 2 writes - but the results remain the same even for 0.5 MTU (or smaller) which would be a single write per message. There is some escaping of special characters but for the most part it is f*MTU. Apple always sets the MTU to 512 (from what we have seen).

Note that Dart’s .timeout() doesn’t cancel the BLE write underneath it

This is an interesting observation (@heidi-bmec-co , @aqeel-bmec-co ). While the timeout() will throw and break out of that for loop, looking up our stack it will then pull the next item from our queue and could result in a second write before the first write completes. Thanks for picking this up, it could make things worse however the root issue occurs long before there is a timeout. We'll comment for our testing to avoid muddying the waters.

[heidi-bmec-co]

@fotiDim

Does the RTT still increase with QueueType.perDevice when only one device is connected and sending?

Yes, one device connected, QueueType.perDevice, timeout commented:

[fotiDim]

@raphael-bmec-co @heidi-bmec-co could you capture timestamps immediately before and after each UniversalBle.write(), along with the native WRITE -> debug logs, for about 10 writes using both perDevice and none?
That will separate time spent waiting in UniversalBle’s Dart queue from time spent waiting for CoreBluetooth’s write acknowledgement.

[heidi-bmec-co]

@fotiDim I have attached some log files as per your request. Please let me know if this is what you were looking for.

QueueType.noneV2.txt
QueueType.perDeviceV2.txt