Periodic background location polling for infrequently used app

My team and I would like to develop a mechanism that collects the user’s location a few times per day, to detect when the user travels to a different country, for the user’s convenience. The app is very likely going to be opened very rarely. The user would of course be made aware of why collecting the location a few times a day is desired - namely, saving them the effort of having to remember to open the app every time they travel.

My question is the following: given that the app would rarely be interacted with, what is the best strategy for collecting the location? The goal is to handle scenarios where the OS might avoid sending location events or notifications to the app. I imagine that the backend might need to intervene and send the occasional push notification to remind the user to open the app from time to time.

There are 3 strategies that I’m aware of:

  1. LocationManager’s startMonitoringSignificantLocationChanges
  2. Scheduling BGAppRefreshTasks
  3. Using silent push notifications scheduled by the server. Ideally, using a location push service extension

Keeping in mind the “Background execution demystified” WWDC session, documentation, and other threads, I concluded the following:

  1. The first idea is probably the least suitable, since it probably requires the app to be opened often, and the location updates would not be sent by OS if the app has been terminated from the app switcher.
  2. The second approach would also suffer from infrequent use and termination.
  3. The third approach seems not to be affected as much by infrequent usage. I understand that the 3rd strategy might also lead to the OS omitting to wake up the app when it has been terminated by the user.

How would you implement this mechanism?

Answered by Engineer in 789557022

Actually, the first approach would be the only one that is not effected by infrequent use and user termination. But the downside is, it will collect the location far more than a few times per day - unless the device is just sitting in a drawer all day.

While silent push notifications will not work for apps that are terminated or rarely used, a location push service extension would not be effected by those conditions. The difficulty there is, though, to obtain the special entitlement required to use location pushes.

Actually, the first approach would be the only one that is not effected by infrequent use and user termination. But the downside is, it will collect the location far more than a few times per day - unless the device is just sitting in a drawer all day.

While silent push notifications will not work for apps that are terminated or rarely used, a location push service extension would not be effected by those conditions. The difficulty there is, though, to obtain the special entitlement required to use location pushes.

There's another way that you could choose - I've used it in a project after I ruled out significantLocationChanges because it woke the app up too often, and even when there was no change in location.

Try region monitoring. Set a large region around the user, and have the system wake the app when the user leaves the region. When that happens, set another large region around their new location. With this method, you get to decide just how "significant" the location change needs to be, and you also prevent the unnecessary wake-ups caused by the standard "significantLocationChanges".

Periodic background location polling for infrequently used app
 
 
Q