Posts

Post not yet marked as solved
4 Replies
4.3k Views
Hello everyone!We are developing an app that needs to work in foreground, background and even when the user kills it deliberately. Also, we need to get bluetooth switch events. Entries to and exits from a region and bluetooth switch events fire a communication event with a server that takes no longer than 2 seconds.Our app acts as a central BLE device and monitors a custom iBeacon region. We want to monitorize an unknown number of regions with the same UUID, so the limitation of 20 iBeacon regions drove us to start monitoring without specifying the minor and major values and to retrieve those values with ranging.We know that Apple needs proper justifications for using background modes in an app. We do not intend to benefit ourselves with the use of background modes but to ease the user experience and to quick response to BLE detection.Key points:Running in foreground works perfectly.Ranging in background was not working (that is normal) so we added location background modes (along with allowsBackgroundLocationUpdates set to true) to range beacons continuously.didEnterRegion and didExitRegion worked when app was killed but bluetooth switch events were not received. That is why we added bluetooth-central background modes support.We noticed that sometimes, didEnterRegion or didExitRegion events were not propertly fired when these two background modes were not added and the app was killed. After adding these two background modes, those events were fired according to specification.Are we incurring in some Apple guideline violation with the use of these background modes? Would our app be rejected if we use this background modes? User experience is fundamental for us and with these background modes we have acomplished a full user experience.Thank you very much in advance.
Posted
by misla.
Last updated
.