Similar here on iPhone 17 Pro Max, iOS 27.2 — but a different shape, so worth checking whether it's the same root cause. Mine is background delivery stopping entirely, not stuttering. With the app backgrounded I get stretches of 5 to 9 minutes with zero fixes delivered, then they resume the moment the app comes forward. With the app open on screen on the same ground, the same walk records perfectly at ±3 m with nothing rejected. Two questions: does yours also recover immediately when the app comes to the foreground, or does it keep stuttering while active? And is your app using a background location session, or only foreground updates?

Closing the loop, since the thread should end with the answer. Two causes, both confirmed on the road with an instrumented build: expo-location (19.0.8) never creates a CLBackgroundActivitySession. It uses only the legacy allowsBackgroundLocationUpdates path. A native app on the same phone (Hunt Buddy, While Using only) kept the background location indicator on indefinitely; mine lost it about 60 s after backgrounding. Adding a CLBackgroundActivitySession in the Expo task consumer (created before startUpdatingLocation, invalidated on stop, iOS 17+) fixed that: the indicator now stays on for as long as the session runs. With the map screen mounted, my own foreground position watcher and a 5-second UI tick kept re-rendering a ~750-child map view in the background, starving the location callback. Pausing those while the app is not active brought the per-delivery cost from ~150 ms to under 20 ms, and the suspensions stopped. Result: 22-minute drive, app backgrounded, screen off, no gaps. Thanks for the pointers - the "not being kept alive by its location session" framing and the "taking too long to process updates" note from thread 786558 were both right.

Result from a second instrumented drive, same no-filter configuration, with a ledger attached to my crash reports so I can see exactly what my code did before each gap. My code made no start, stop or reconfigure call to the location manager at any point during the drive. The only events before each gap were app-state transitions. Deliveries stopped about 50 seconds after the app entered the background, both times it did so (51 s and 47 s). Gaps of 74 s and 138 s ended only when I brought the app to the foreground. A 45 s gap earlier ended on its own, presumably a significant-change wake. showsBackgroundLocationIndicator = YES throughout, authorization is Always with Precise Location on, distanceFilter unset, BestForNavigation, pausesLocationUpdatesAutomatically = NO. Then a direct observation of the same thing, stationary, no drive: start the session in the foreground, go to the home screen, and the blue background-location indicator appears in the Dynamic Island. It disappears after roughly one minute. The app makes no call during that minute. So a session started in the foreground and never touched again loses background location about a minute after backgrounding, and the system indicator confirms it. The timing looks like the ordinary background grace period, as if the app were not being kept alive by its location session. iPhone 17 Pro Max, iOS 27.0 beta; the same gaps were present on iOS 26. I can capture a sysdiagnose immediately after the indicator disappears if that would help.

Follow-up with a test result. I built a TestFlight version using exactly the configuration from thread 726945 and drove it for about 40 minutes, app in background, screen off: desiredAccuracy = kCLLocationAccuracyBestForNavigation distanceFilter = kCLDistanceFilterNone (not set at all) pausesLocationUpdatesAutomatically = NO showsBackgroundLocationIndicator = YES allowsBackgroundLocationUpdates = YES activityType = CLActivityTypeOtherNavigation UIBackgroundModes includes location Result: deliveries arrived every 5-6 seconds between suspensions, so the configuration was in effect. But the app was still suspended for stretches of 5 minutes and 8 minutes during the drive, with no code of mine running at all during those windows. Roughly two thirds of the route was lost. So with both the indicator set and no distance filter, the app is still suspended while driving. This is on iOS 27.0 beta, and the same behaviour was present on iOS 26. Given that, is the remaining difference the unconditional call to startMonitoringSignificantLocationChanges that expo-location makes on the same manager? If so, I can patch that out and test. If there is something else you would want me to look at first, I would rather run that test.

Thanks Albert. Answering your questions directly, and correcting two things in my original post. iOS 26 vs iOS 27 My original title was misleading and I apologise. I am on iOS 27.0 beta, updated 2 September. But the gaps were present on iOS 26 as well. This is not an iOS 27 regression. It is long-standing behaviour that I only investigated properly after updating. Have I contacted the third party Not yet. I will raise it with Expo as well. Worth noting for the thread: expo-location calls startUpdatingLocation and startMonitoringSignificantLocationChanges back to back, unconditionally, on the same manager, with no way to opt out. So my app is inside the case described in thread 726945 whether I want to be or not. Does iOS suspend an app with an active standard location session That is what I am observing, and I want to be careful about the claim. During the gaps no code of mine runs at all - no logging of any kind, not just no location callbacks. Deliveries resume on a significant-location-change event or when I foreground the app. allowsBackgroundLocationUpdates Yes, set to true, verified at runtime. CORRECTION TO MY CONFIGURATION The distanceFilter in my original post was wrong. It came from a diagnostic build. My shipping configuration is: desiredAccuracy = kCLLocationAccuracyBestForNavigation distanceFilter = 5.0 pausesLocationUpdatesAutomatically = NO showsBackgroundLocationIndicator = YES allowsBackgroundLocationUpdates = YES activityType = CLActivityTypeOtherNavigation So I satisfy the accuracy half of the guidance in thread 726945 and not the distance filtering half. MY ACTUAL QUESTION Thread 726945 says the issue can alternatively be avoided by setting showsBackgroundLocationIndicator to YES. I have had that set to YES throughout, on every failing drive. Is that alternative still valid on current iOS, or has it been superseded? If the indicator is meant to prevent suspension and does not, that is the part I most need to understand. I have not yet tested the no-filter configuration on a drive. If the indicator alternative is no longer valid, that is my next test.