Hello Apple Developer Community, I'm developing a cross-platform app using Flutter and the flutter_beacon library to handle iBeacon detection on iOS. My goal is to wake up the app in the background when it's in a killed/terminated state upon entering/exiting beacon regions, allowing for BLE communication (e.g., ranging or connecting to beacons). I've configured the necessary Info.plist keys for always location access and background location modes, and it works partially for single regions, but I have some specific questions/issues regarding reliability and limitations: Background Execution Time After Wake-Up: When the app is woken in the background by a region monitoring event (enter/exit) from a killed state, approximately how much time (in seconds) does iOS allocate for the app to run before suspending it again? Is this sufficient for performing BLE operations like ranging beacons or establishing a short connection, or are there stricter limits in terminated wake-ups compared to standard background modes? Monitoring Multiple iBeacons with Unique Identifiers: I need to monitor multiple iBeacon devices, each with potentially different UUIDs, majors, and minors. Can I add and monitor up to 20 regions simultaneously, each with a unique string identifier? If multiple beacons (from different regions) enter their respective ranges at around the same time, will the app receive separate callbacks for each region/identifier, or is there coalescing/prioritization that might cause only the last-added identifier to trigger notifications/events? Reliability in Killed State: In a fully killed state (e.g., force-quit via app switcher), does iOS reliably relaunch the app in the background for region monitoring events? Are there any known caveats, such as requiring specific hardware (e.g., iPhone models with certain Bluetooth chips) or iOS versions (targeting iOS 14+), and how does this interact with Flutter's background execution handling via the flutter_beacon library?
iBeacon Monitoring in Flutter App: Background Wake-Up from Killed State, Time Limits for BLE, and Handling Multiple Regions/Identifiers
There are a few questions in this block. Let me try to take them apart.
Background Execution Time After Wake-Up: When the app is woken in the background by a region monitoring event (enter/exit) from a killed state, approximately how much time (in seconds) does iOS allocate for the app to run before suspending it again?
You can generally expect about 10 seconds when the app is woken up. This is the total time. If the app has been terminated, depending on how long it takes for your app to finish launching, you would end up with less than that.
The beginBackgroundTask(expirationHandler:) API can be used to request up to 30 seconds, but it is not guaranteed that you will get that much. The system can also re-suspend or terminate your app in much shorter a time if it needs the resources your app is using urgently.
Is this sufficient for performing BLE operations like ranging beacons or establishing a short connection, or are there stricter limits in terminated wake-ups compared to standard background modes?
This is unlikely to be adequate time to scan for a device, establish a connection, and transfer data unless the peripheral yo are trying to connect to is advertising at a rate of 20ms, which is the only way a connection within 30 seconds is guaranteed. There is no strickter rules for terminated/relaunched apps than backgrounded apps as far as Bluetooth connection time is concerned (they will both be very slow), but considering my above point of time for relaunch, re-establishing your CoreBluetooth objects and starting to scan/connect, there will be no telling if what you are planning to o will succeed in the given time at any point. If you need this to work reliably, it will likely will not be.
Monitoring Multiple iBeacons with Unique Identifiers: I need to monitor multiple iBeacon devices, each with potentially different UUIDs, majors, and minors. Can I add and monitor up to 20 regions simultaneously, each with a unique string identifier? If multiple beacons (from different regions) enter their respective ranges at around the same time, will the app receive separate callbacks for each region/identifier, or is there coalescing/prioritization that might cause only the last-added identifier to trigger notifications/events?
One limit to understand is that CoreLocation will wakeup/relaunch your app only once every 3-5 minutes, if region events occur back to back. If the app is already active, you may get the individual callbacks. There are a lot of power saving measures in place, so the exact behavior will vary based on conditions.
Reliability in Killed State: In a fully killed state (e.g., force-quit via app switcher), does iOS reliably relaunch the app in the background for region monitoring events? Are there any known caveats, such as requiring specific hardware (e.g., iPhone models with certain Bluetooth chips) or iOS versions (targeting iOS 14+),
Region Monitoring has been present in iOS and iPhones for a long time, so any iPhone running iOS 14+ should be OK. Any differences in behavior you see are more likely to be caused by individual device states than model or iOS versions.
and how does this interact with Flutter's background execution handling via the flutter_beacon library?
For that, you would need to ask the support channels for Flutter, unless someone here in the community has an answer for you.
Argun Tekant / WWDR Engineering / Core Technologies