Possible to get detected beacon info in didEnterRegion?

I believe this has been covered but I want to make sure I understand things correctly.

If I for example perform background monitoring for a region defined only be a UUID, then there is no way, without ranging, to get the major/minor values of the beacon that triggered the didEnterRegion method. Is that correct? And that in order to perform ranging, the app must be in the foreground?

I would imagine a popular use case (and exactly what I am trying to do) would be something like grab the beacon that triggered didEnterRegion, get the major/minor values and get some dynamic text via HTTPS from an external server and display that text in a local notification. Must I use ranging for this? I see ranging in the background is not recommended due to battery consumption and also Apple sometimes reject apps that require background ranging.

Any idea if this capability will be added in a future iOS update? Any possibility of the Estimate SDK adding this capability? iOS must collect this data from the beacon that triggers didEnterRegion so why not allow the app to access it? Even if it was an array of beacons it would be very useful.

Thanks for your response.

1 Like

Extremely good and well-researched question, thank you for this write-up! (would up-vote if this were Stack Overflow :wink:)

You’re correct that there’s no way to discover the major/minor without ranging in a setup where you monitor by UUID only.

You’re also correct that continuous ranging in the background is heavily discouraged, and that Apple often rejects app that do that. That’s because to be able to continuously range in the background, your app needs to use the Location background mode, and Apple reviewers are very strict about these. You need to prove there’s value for the user from doing that.

However, ranging in the background for short periods of time, upon enter/exit events being triggered, is totally fine. When an enter/exit happens, iOS wakes your app for ~ 10 seconds in the background to handle the event—and you can use this time to do ranging. This doesn’t require any special permissions (apart from the “always” permission to access location data, required for monitoring) or background modes, and so doesn’t require any extra argumentation for app review.

What’s more, you can use the ~ 10 second window to start a background execution task, which will grant your app up to ~ 3 minutes extra background time. This also doesn’t require any special permissions or handling during review, and is perfectly legal. Naturally, doing this very often to run ranging in the background will contribute to increased battery drain, so use this option a bit more consciously. Nobody wants their app uninstalled b/c they find out it drains the battery in the background. (iOS 9 shows foreground/background separately on the Battery Usage screen.)

Thanks so much for confirming this. I actually went ahead and experimented with the ranging before your reply and as you noted it works perfectly. Knowing that this method is acceptable is of great use. Thanks again. I’m not sure I even need a background task. Early in my testing it only takes a second or two to range the beacon and perform a https request to get grab some data to display in the notification. I’ll have to test more under degraded network conditions. Either way, there shouldn’t be significant battery drain since for my application, this background ranging would only be required very briefly upon entering a region. Entering a region would be a relatively infrequent event, a handful of times during a week at most. Thanks so much to the iBeacon team. These devices are really cool and work really well.

1 Like