Background Location Tracking Not Reliably Relaunching App After Termination

Question

Rutvik_Panchal OP

Created 3w

Replies 4

Boosts 0

Participants 2

We are developing a mileage tracking application that depends on continuous background location updates on iOS.

Our app has the required background modes enabled:

<key>UIBackgroundModes</key>
<array>
    <string>remote-notification</string>
    <string>processing</string>
    <string>fetch</string>
    <string>location</string>
</array>

We are observing inconsistent behavior with background location tracking in app terminated state.

In some cases, after a period of time, location updates stop completely. Sometimes iOS successfully relaunches the app when movement is detected and location updates resume correctly. However, in other cases, the app is not relaunched by the system, and we stop receiving location updates entirely.

We reviewed Apple’s documentation on handling background location updates: https://developer.apple.com/documentation/corelocation/handling-location-updates-in-the-background

Based on our observations, we would appreciate clarification on the following points:

Is this considered expected iOS behavior or a system limitation?
Under what conditions does iOS decide not to relaunch a terminated app for location events?
Are there recommended best practices to improve the reliability of background location relaunch behavior?
Is there any logging, diagnostics, or debugging mechanism available to determine why the app was not relaunched?

Apple’s documentation mentions that location updates may be queued while the app is terminated and later delivered after relaunch. However, in some scenarios we do not receive those queued updates after the app restarts. Under what conditions can queued location updates be discarded or not delivered?

Additional notes:

We are using standard Core Location background updates. “Always” location permission is granted. Background App Refresh is enabled. The issue is observed intermittently across multiple iOS devices.

Answer 1

Engineer OP

Apple

2w

Only some of the location APIs will relaunch aps after termination, and the reliability issue you are observing could be expectations beyond what those APIs will provide.

Let's start with finding out which CoreLocation APIs you are using?

Usually we find that "reliability" depends on what you are expecting vs. what the APIs provide, and sometimes if you are stacking several APIs together they may be stepping on each other and leaving your app unmonitored.

Please provide which APIs you are using and if more than one, how are you using them together.

Answer 2

Rutvik_Panchal OP

2w

Thank you for the response.

Here is the precise breakdown of the CoreLocation APIs being used. We are using a single third-party Flutter plugin: flutter_background_geolocation v4.18.1 by Transistor Software. We are not using any direct CoreLocation calls ourselves - all location work goes through this plugin's native iOS layer.

APIs the plugin uses internally on iOS Based on the plugin's native debug logs and its documented behavior, it stacks the following CoreLocation APIs:

startUpdatingLocation - used when the device is in moving state, at high accuracy with our 5m distance filter
startMonitoringSignificantLocationChanges (SLC) - used as the primary relaunch-after-termination mechanism when the device is stationary
Circular region monitoring (startMonitoringForRegion) - a "stationary geofence" is placed at the user's last known position (200m radius per our stationaryRadius: 200 config). When the user exits this region, it acts as a secondary relaunch trigger
CMMotionActivityManager - used for its internal stationary/moving state machine (disableMotionActivityUpdates: false in our config)

Our exact plugin configuration

bg.Config(
desiredAccuracy: bg.Config.DESIRED_ACCURACY_HIGH,
  distanceFilter: 5,
  stopOnTerminate: false,
  startOnBoot: true,
  stationaryRadius: 200,
  preventSuspend: true,
  disableMotionActivityUpdates: false,
  heartbeatInterval: 60,
  locationAuthorizationRequest: 'Always',
  showsBackgroundLocationIndicator: true,
  useSignificantChangesOnly: false,
  foregroundService: true,
  enableHeadless: true,
)

How these APIs are used together The plugin operates a state machine:

Stationary state → startUpdatingLocation is stopped, SLC + stationary circular geofence (200m) are active together as dual relaunch triggers
Moving state → startUpdatingLocation is active, SLC remains running in the background as a safety net

So when the app is terminated and the user is stationary, SLC and a circular geofence region are both active simultaneously as the relaunch mechanism.

What we observe

The relaunch works correctly in many cases. But sometime in terminate state of the app the SLC nor the geofence exit triggers a relaunch, and location tracking stops entirely until the user manually opens the app.

Answer 3

Engineer OP

Apple

2w

This sounds like something the developers of the plugin should debug and find out why location updates are stopping.

I can think of various things that could be getting used in a way that deadlocks the flow, or simply doesn't work as expected, but as a user of the plugin there is unlikely to be anything you can do about it.

Answer 4

Rutvik_Panchal OP

2w

Thanks for your response.

At the moment, we are using a third-party location tracking plugin, so we do not have full visibility into its internal implementation. Based on our understanding, the plugin relies on a geofencing approach where background location monitoring is started and the application is expected to be relaunched when the device exits a geofence (approximately a 200-meter radius).

The issue we are seeing is that, in some cases, the app is not relaunched when it is in a terminated state. This behavior is intermittent and does not occur consistently. In many cases the relaunch works as expected, but occasionally it does not, which results in missed location updates.

We have also observed similar behavior in other applications that use background trip detection, such as Driversnote, where trip detection is sometimes missed when the app is terminated. This makes us wonder whether the limitation could be related to iOS background execution policies or geofence wake-up reliability rather than a deadlock within our application logic.