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!
Even if your app is always in the foreground, the scanning will slow down with time.
Your stopping/starting the scan every 10 seconds to work around this behavior would be considered abuse. While it is in the end up to you, it is an unsupported workaround, and you may encounter unexpected behaviors.
