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.

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.