Background operations

In some cases you may be interested in utilizing location also in the background. This may be for example for geofencing or in order to collect analytics about how the venue is utilized. What you need to take into consideration are App Store / Play Store requirements and best practices, and limitations posed by the operating systems. There are a number of tricks that you need to keep in mind for both iOS and Android.

Let's first determine what we mean by background and foreground:

Foreground: App in active use. Android has another situation when app is in foreground mode. More on that below.

Background: Background refers to situations, when your app is not actively in use. For example, when you are browsing Facebook, you are using in in the foreground. But when you switch to another app – or when you are not using your phone at all, Facebook goes into background mode. The technical details of how that transition happens, depends on the phone model. For example on iOS, part of the background mode is called “suspended mode”. In order of clarity, we will summarize these different modes of “app not being used” as background. If you want to be able to collect location data or detect geofences to your app users, even if they are not at that exact moment browsing it, you need to implement some kind of background support.

iOS

In general, your app gets no background time for requesting the position – or any other use. When you app goes to background mode, it gets around 5 seconds of background time. After that there is silence.

Full background support: iOS has the capability of enabling the Background Location Mode in your app, which will allow you to constantly poll for location. That is great for you, but not for the battery. Therefore Apple only permits apps that have a functional reason for that, for example running apps, into App Store. It is very likely that your app does not fulfill these requirements, so this option should not be utilized, unless you are fully sure of it.

Other possibilities: There are two other App Store approved ways of getting location data in the background, which the Proximi.io SDK utilizes by default: significant change and Core BLE.

iOS significant-location-change feature. iOS operating system can recognize, when the user has started walking. This works typically very well for different use cases. The downside of those is that you need to physically move quite long distances in order to receive a “significant change”. The length of that distance depend on how fast you are moving, what type of area it is etc, but we are talking typically at least a couple of blocks.
Core BLE. iOS operating system has the capability of waking up, upon detecting a BLE beacon. If you are doing geofence-type detection, you can have one iBeacon in each location, which will wake up the app. If you would need continuous background operation across a large area, we recommend a mixed installation of iBeacon and Eddystone beacons. The two protocols in turn each wake up the application.
Extended background time. Whenever the app is woken up, we are additionally requesting for extended background time (around 3 minutes). This extra time is utilized to poll for location.

These capabilities are already built-in the Proximi.io SDK. No changes on the app level are required from you. Apart from naturally a privacy policy explaining data usage.

Other limitations: The operating system gives the user the possibility to select, whether the app can utilize location always, while app is in use, once or never. In order to get the user to select "always", it is recommended to communicate the benefits of the application to the user as clearly as possible.

It is also noteworthy that you cannot request for "always" permission from the application upon first opening the application. The options shown will be while in use, once and never. If you have specified in your application that an "always" permission would be preferred, the operating system will show a request after a while of using it.

Examples of what the user permission request looks like:

The feared iOS11 blue bar. Currently the status of whether or not a blue bar is show, when an app uses location changes with every iOS version. At the moment, by default the blue bar will not appear when you use location in the background, when the application user has given a permission for that.

Android

With the Play Store spring 2021 requirements, the use of background location data is also tightly controlled on Android.

Your options are:

1) Explaining why your app requires background location permissions

You can now submit your app for feedback on location in the background access by completing the Location permissions declaration form in Play Console. You should highlight the benefit of background location usgae for the end user.

Your app should not request access to location in the background unless it’s required. If your app requests access to location in the background but it’s not critical to the app’s core functionality, you must remove it from your app and / or implement location access in the foreground, such as when your app’s activity is visible to users. You can find details on policy compliant implementation from the following link: https://support.google.com/googleplay/android-developer/answer/9799150?hl=en.

2) Utilize a foreground notification

In cases where our SDK's foreground notification is utilized, location access counts as "foreground". This means that in these cases the background location is not used and there's no need to complete the Location permissions declaration form. When our SDK's foreground notification is disabled, background location should be used and it is also required to fill up the form via Play Console.

3) Only use location data in the foreground

For optimal background operation, for example for use cases with continuous location sharing, opt for option 2. You may also explore the possibility of utilizing silent notifications for waking the app up intermittently. Some of our customers have found that it improves with background operation. There are still some phone models that very actively kill all the applications, when the phone screen is closed.

Other limitations: Some Android manufacturers also give user the possibility to select, whether the app can utilize location always, while app is in use, once or never. In order to get the user to select "always", it is recommended to communicate the benefits of the application to the user as clearly as possible.