- Does the Background Mode have limitations?
- How does the battery saver affect background execution?
- Would it be possible to relaunch the app if the system or the user closes it?
- Will the user notice that the app is running on the background?
- Are there alternatives to the Apple Store regarding app distribution?
If you want to use Situm for tracking, your app will need to execute continuously in the background.
An app is running in the background either if the app has been minimized, if another app is showing on the smartphone screen, or if the smartphone screen has been blocked. In either of these situations, Android & iOS may kill the app or at least not allow it to full access to the smartphone’s computing power (obviously harming the app performance).
For some apps, this is not an issue since they should only run in the foreground (e.g. wayfinding apps, where the user is expected to be interacting with the screen while being guided). For other apps (e.g. tracking apps), this will cause many inconveniences. Luckily, Situm provides mechanisms to avoid this and ensure that your apps keep up & running in the background.
As explained in the Android documentation (see Optimizing for Doze and App Standby and Background execution limits), Android may kill your app if it is running in the background in order to increase the battery life of the smartphone. To avoid this, you will need to implement one of the following mechanisms.
Running Situm SDK as a Foreground Service (recommended) #
The first and the most recommended method is to enable the Situm SDK option that allows to run it as a Foreground Service (this option also implements other advanced configurations to maximize the chances that Situm SDK keeps running). This comes at the following costs:
- Users will see an always-on status bar notification.
- Battery consumption will obviously grow, since positioning will run continuosly.
LocationRequest locationRequest = new LocationRequest.Builder().useForegroundService(false).build();
Customizing the persistent notification #
Running Situm SDK as a Foreground Service will show your users an status bar notification, as required by Android’s Policies. You may customize this notification in order to:
- Provide your users with information about why the application is being executed in the background.
- Managing interactions with the application from the notification drawer.
LocationRequest locationRequest = new LocationRequest.Builder().useForegroundService(true).foregroundServiceNotification(notification).build();
Running Situm SDK from your own Foreground Service #
The previous option may not be adequate for your app. For instance, your app may need to execute another Foreground Service to run your own code, and you may not want to show two status bar notifications (Situm’s and your own). If this is the case, you may run Situm SDK in your own Foreground Service, provided that you declare its type as “location” (see the Android docs for more details).
In theory, this should have the same effect as the previous option. Be aware, however, that we still recommend the previous option (run Situm SDK as a Foreground Service), since this applies some other configurations to maximize the survival chances.
Running Situm SDK from a background service with the ACCESS_BACKGROUND_LOCATION permission (not recommended) #
There’s a way to allow apps to run in the background indefinitely without showing the user the always-on status bar notification: you may achieve this if the user grants you the ACCESS_BACKGROUND_LOCATION permission. However, we do not recommend this method because this is a highly sensitive permission and, so according to Google guidelines you will need to justify why you need it before publishing your app in Google Play.
iOS distinguishes two background operation modes:
- Finite task background execution. This mechanism allows to finish long tasks, which cannot be interrupted, when the app goes to background. This execution mode imposes restrictions when an app takes too long to complete those tasks or makes excessive use of this mechanism (e.g. may kill the app in this case).
- This mode is viable, for instance, if we want to keep computing the user geolocation for some seconds/minutes after the user blocks the screen.
- Background mode. This mode allows to keep the application running in the background forever (or at least, for long periods of time).
Obviously, the “Background Mode” is the recommended to build tracking apps: allows us to compute the geolocation of the user at all times. There are a number of cases in which the use of this mode is allowed in iOS, including positioning and guidance. By activating the required permission at the app level, it is possible to compile an app that uses Situm and keeps the positioning in the background.
This solves the problem from a technical perspective. Nevertheless, from an operational perspective it is important to take into account that Apple must aprove the distribution of the app in the App Store. Specifically, Apple must allow the use of this permission. Apple evaluation includes, among other things, a validation of the reasons why the app wants access to the user’s position.
As an alternative, in case this approval results problematic, would be to use an Enterprise App Store. This option will probably have a less extensive evaluation of the apps, but a number of requirements must be met in order to become a member of this program.
Does the Background Mode have limitations? #
With the second option, an app using our SDK will be processed in the same background as, for example, a mail app. When the battery saver mode is activated, the system can limit partially its functionality, but in principle it should not reach the point that Situm positioning stops working acceptably. In any case, this is totally at the mercy of the specific device, system-operational and its battery saving policies.
How does the battery saver affect background execution? #
In our experience, apps can run for hours/days without being affected by the battery saver limitations. Anyway, this depends on the Operating System, which might introduce discretional limitations to the background execution of the app, reducing its performance or even killing it. There is not much information available regarding these conditions about under which conditions the system may decide to limit the operation of the app or even kill it (iOS: 11 continuous background location update by swift ). An important factor will be the battery consumption of the app: the higher it is, the higher the change the OS might kill it. This is specially true if the “Battery Saver” mode of the OS is activated.What seems assured, is that an app will not be able to run in backgrounds for days without the system eventually closing the app. To alleviate this, there are mechanisms associated with the Background Mode that allow an app to be launched in response to certain events. See the article “About the background execution sequence” for more information.
Would it be possible to relaunch the app if the system or the user closes it? #
Yes, but only if the app has the Background Mode permission activated. We can react to three types of events (Handling location events in the background) in order to relaunch the app:
Will the user notice that the app is running on the background? #
Yes. In all iOS systems the use of background location shall be marked by an indicator on the system bar at the top. Additionally, in iOS 13 and later, the use of background location can launch a popup to show the user the last positions obtained and confirm that he wants to continue allowing that access to the location in the background. This warning can show up repeatedly, and it is up to the iOS system to decide when to launch it.
Are there alternatives to the Apple Store regarding app distribution? #
There are essentially 4 ways of distributing an iOS app:
- App Store. This is the standard way. Keep in mind that Apple needs to aprove your app. If your app needs to run in Background Mode, you will need the apropriate permissions and Apple will review your app to decide whether it grants them.
- Enterprise App Store. This is a private store that allows large organizations to develop and deploy proprietary, internal-use apps to their employees. In principle, Apple will not need to aprove your app or the permissions it asks. The usage of this program is restricted to large organizations (100+ employees), for internal apps only. More details here.
- TestFlight. This is a private channel designed to distribute beta versions of apps to internal & external testers (up to 10000 external users). Apps can be accessed during 90 days (after which you need to re-upload them & users need to re-download them). More details here.
- Signed IPA. Just like in Android you can send APKs that users can download & install in their phones (e.g. over email), in iOS you can send IPA files with the same purpose. The caveat is that the app needs to include the Apple ID of all the smartphones where you want it to run. Therefore, if you want to send the IPA to a new user, you will need to include the Apple ID of her smartphone in the app’s source code & recompile.