Background execution window after CLBeaconRegion wake from terminated state

Hello, I am using CLLocationManager to monitor multiple CLBeaconRegion instances (up to 20). When the app is terminated by the system (not force-quit) and a region enter event occurs, the app is relaunched in the background. I have two questions: What is the expected execution time window after relaunch before the app is suspended again?

This is a trickier question than it seems, as there is a pretty big difference between what our documentation says and real-world behavior. Splitting those questions up:

Documented Behavior:

With a few exceptions, our documentation doesn't actually say how long your process will stay awake after it's been woken, so strictly speaking, the system COULD suspend your process immediately after it returns from whatever callback woke it. That leads to...

Actual Behavior:

...however, the actual behavior here varies WIDELY, typically with an upper boundary of ~30s and a lower bound of "immediately after return". Generally speaking, the difference here matches up with when the API was introduced, with older APIs having much longer time windows than newer APIs. However...

Solution:

...the correct answer here is that you should NOT be relying on the system to keep your process awake. If you want to be awake, use UIApplication.beginBackgroundTask(withName:...) to keep yourself awake. That will give you ~30s of runtime, which you can use for whatever you need to do. Note that this recommendation applies to basically ALL cases— anytime you're asking "how long will the system keep me awake", the proper approach is to assume that it won't and use beginBackgroundTask to keep yourself awake instead.

That leads to here:

Is it supported to start short CoreBluetooth operations (e.g., scanning or connecting briefly) within this window?

In general, the reason an app is awake in the background doesn't really change orrestrict what that app can do in the background. So, yes, this is possible. Note that CoreBluetooth also has its own background category to allow extended Bluetooth interactions from the background, which could then be used for longer exchanges.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hello, We are using iBeacon region monitoring with CLLocationManager (startMonitoring(for:)) to detect entry into a specific beacon region.

Setup: Background Modes enabled: location bluetooth-central “Always” location permission granted. iBeacon UUID configured correctly. Beacon hardware verified (advertising confirmed).

Expected Behavior: When the device enters the beacon region, the app should wake (or relaunch) in the background and trigger BLE communication. Observed Behavior: If the app is sent to the background normally → region enter event works correctly. However, if the user force-quits (swipe up kills) the app, then: The app does not relaunch when entering the beacon region. didEnterRegion is not triggered. BLE communication does not start. Questions: Is it officially supported for iBeacon region monitoring to relaunch an app after the user force-quits it? Is this behavior intentionally blocked by iOS as a user privacy/power decision? Are there any supported mechanisms to resume beacon monitoring after a force-quit?

Observed Behaviour We tested around 50 entry events: ✅ ~48 times → App wakes correctly in background, region enter event fires, BLE communication starts.

❌ 2 times → App did NOT wake up, region enter delegate was not triggered, and BLE communication did not start.

Does this behavior differ across iOS versions? We want to confirm whether this limitation is by design or if additional configuration is required. Thank you.

(Reordering questions for clarity...)

Questions:

Is this behavior intentionally blocked by iOS as a user privacy/power decision?

So, in general, the "normal" behavior of iOS is that it does not relaunch applications that have been force quit by the user, primarily to simplify the user’s general "management" of background app usage. However...

Is it officially supported for iBeacon region monitoring to relaunch an app after the user force-quits it?

...there are exceptions and, yes, region monitoring is one of them. The issue here is that there are use cases we want to support that don't really "work" within the standard force quit behavior. The canonical example here is supporting airline apps notifying the user when they arrive at the airport, as it isn't really "reasonable" to expect the user to have not force quit an app they may not have used for weeks or even months.

Are there any supported mechanisms to resume beacon monitoring after a force-quit?

Not specifically, no. The main issue here is that your app needs to initialize CoreLocation and set up its region monitors "early" in the app’s launch, generally in applicationDidFinishLaunching. Setting this up too late in the launch sequence can mean things fail if your app happens to suspend before it was able to reconnect.

That leads to here:

Observed Behaviour We tested around 50 entry events: ✅ ~48 times → App wakes correctly in background, region enter event fires, BLE communication starts.

❌ 2 times → App did NOT wake up, region enter delegate was not triggered, and BLE communication did not start.

What were the testing conditions here? In real-world conditions, I'd actually consider 48/50 a complete success. Out in the "real world", there are so many edge cases and odd circumstances that you're simply never going to get 100% success. Similarly, in controlled testing, you need to be very careful that your testing process is "right". For example, region triggering is largely driven by heuristics, so moving the device between entry/exit conditions "fast enough" can cause the device to "miss" the events you’re expecting simply because the device heuristics decided the transition hasn't actually happened.

Does this behavior differ across iOS versions?

That's a trickier question to answer than you think. The behavior itself hasn't really changed since we introduced region monitoring. However:

• There have definitely been bugs in this area, particularly before ~iOS 16. I'm not aware of any major issue since then, but I also wouldn't be surprised if there had been minor failures that I wasn't aware of.

• All failure cases look "the same" ("my region didn't trigger"), which means you can't really know whether anything went "wrong" based solely on whether or not a region didn't trigger.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware