Title: Background location deliveries stop after 2-5 minutes on iOS 27 despite guidance-compliant configuration

Thanks for the post. You mention iOS 27.0 but you do not mention if that was working on iOS 26+ and what beta of iOS 27?

You also mentioned React Native and a library called expo-location 19.0.8? Have you engaged their support system? Does iOS suspend an app with an active standard location session? Is the background active allowsBackgroundLocationUpdates on the project?

I would suggest you to check with the support resources provided by the 3rd party to get assistance with their software.

Unless another developer in the forums has experience with the third-party and can provide assistance.

Wish you luck on your project.

Albert  WWDR

Thanks Albert. Answering your questions directly, and correcting two things in my original post.

1. 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.

1. 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.

1. 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.

1. 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.

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.

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.

Closing the loop, since the thread should end with the answer.

Two causes, both confirmed on the road with an instrumented build:

1. 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.

2. 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.

I’m experiencing the same issue on iPadOS 27 on a Cellular iPad.

It affects all navigation apps I’ve tested, not just Apple Maps. The map rendering itself is perfectly smooth, but the GPS/location position is unstable and updates in noticeable jumps/stutters while driving.

Since the same behavior occurs across different navigation apps, it seems to be related to iPadOS/Core Location/GPS rather than a specific navigation app.

I did not have this behavior before updating to iPadOS 27…

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?