Background in iOS


There are a number of cases in which the use of background is allowed in iOS, including positioning and guidance. 


Therefore, by activating the required permission at the app level, it would be possible to compile an app that uses Situm and keeps the positioning in the background. It solves the problem on its level of technical development, but other concerns arise regarding the distribution of the app. 


Apps that use the background mode, under one of the precepts allowed by Apple, must pass a review process in order to be accepted for distribution through App Store, more in:  iOS App Store rejections with the “location” background model


This evaluation includes not only the app technical operation, but also includes a validation of the reasons about why we want to access the user's position. This evaluation would be carried out at the time when the app developer (Situm or any other) uploads his app for distribution. 


A alternative, in case if this approval results problematic, would be the use of App Store Enterprise , more focused on B2B. 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.



What system limitations are there to background execution? 


To answer this question, we distinguish between two background modes of operation:


  • Finite task background execution: This mode is accessible by any app, without the need to justify any of the cases allowed for 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.


  • Background modes: This would be the case described in the previous section. If we enable background position use (and get Apple to approve it for distribution), we could keep our background operation without being penalized by the system.


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?


As partially explained in the previous question, if we activate the background mode, the system should allow the app to continue running in background for a reasonable time. There is not much information available 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 ). 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 background mode that allow an app to be launched in response to certain events:  About the background execution sequence 


Would it be possible to relaunch the app if the system or the user closes it?


Yes, in case that the app has the background location permission activated. We can react to three types of events

(Handling location events in the background), in order to relaunch the app:


How does the user experience this?


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 the user to show him 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 throughout the use of an app, and it is up to the iOS system to decide when to launch it.


Risks 


  • The approval process of the app to be uploaded to the App Store is a risk. A previous development is required to have an app to submit, and it could be the case that the validation process is extended a lot by Apple, perhaps resulting in a rejection of the app.