iBeacon in the background - Use cases

Question

The number of questions on SO related to iBeacon and its background capabilities is increasing and there is some confusion on that point. I have been testing the AirLocate project.

iBeacon has 2 "capabilities": Region monitoring and Ranging.

Region monitoring is limited to 20 regions and can function in the background (of the listening device) and has different delegates to notify listening app (and user) of entry/exit in the region - even if app is in the background or phone is locked.

Ranging works only in the foreground but will return (to the listening device) an array (unlimited?) of all iBeacons found along with their properties (UUID, etc..)

In addition, that 20 regions monitoring is a device limit. If the user is using geofencing reminders, other apps that use region monitoring; this will lower that number.

1. So are we saying that I can not deploy a mall-wide (100 stores+) app that uses store iBeacons to send a "store specific" notification to the user, while the app is in the background or the phone is locked?

2. I gather that the advertising device (the beacon) has to be in the foreground as well to advertise a region that the listening device could "enter" into. So are we saying, that if the owner of a store had an iOS device; I could not for example save him money by asking him to use his iPhone (at least early on) as an advertising device (beacon) - since the app will likely not always be in the foreground?

3. So in the case of iBeacon + MLB, a single UUID (or <20 UUIDs) is/are used for the app to possibly determine entry door and, then will the user be required to unlock the phone/bring the app to the foreground to use it (find seat, etc..)?

Can I then call the iBeacon: a single location/event (store, park, etc..) feature that requires the user's most "foreground" attention to have a "complete" practical use case?

I have tried to be articulate about the user cases to bring it to practical. Please reply with more than yes or no.

Answer 1

Sounds like you are on the right track. In general you are correct that an app needs to be in the foreground to fully use iBeacon capabilities. A few specifics on your three main questions:

1. Your mall use case can work with a couple of limitations. (a) you have to conserve your CLBeaconRegions by having many or all 100 stores share the same UUID and/or major number, differing only in the minor number. This allows you to set up a single CLBeaconRegion to monitor many. (b) If the app wakes up into the background from seeing iBeacon 1, it won't be able to wake up a second time from seeing iBeacon 2 in the same CLBeaconRegion unless it first stops seeing any other beacon in that CLBeaconRegion. (You can game this a bit by setting up several CLBeaconRegions and trying group stores so adjacent ones in the overlapping 50 meter bluetooth radio range are in different CLBeaconRegions.)

2. No, a store owner cannot use their iPad act as an iBeacon in the background -- it has to be in the foreground to work. But they can have their Windows or Mac computer do this using a virtual iBeacon program. My company offers one for free download: http://developer.radiusnetworks.com/ibeacon/

3. In the door entry use case, yes, the user would have to acknowledge the notification on the lock screen to bring the app into the foreground. A typical implementation would use a single CLBeaconRegion (probably with all iBeacons sharing a ProximityUUID and maybe even a major) to alert the user.