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

Question

wildnx OP

Created 1d

Replies 2

Boosts 0

Participants 2

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

iOS 27.0, iPhone 17 Pro Max. Always authorization, Precise on, Low Power off. React Native / expo-location 19.0.8.

While recording a GPS trail with the app backgrounded and the screen locked, deliveries stop after roughly 2-5 minutes. The JS runtime stops executing entirely — no logging of any kind during the gap. Deliveries resume only on a significant-location-change event or when the user foregrounds the app. Gaps of 6-7 minutes are typical on a 15-minute drive.

Walking does not reproduce it. A stationary phone does not reproduce it. Only driving.

Configuration (expo-location calls both startUpdatingLocation and startMonitoringSignificantLocationChanges on the same manager):

desiredAccuracy = kCLLocationAccuracyBestForNavigation distanceFilter = kCLDistanceFilterNone pausesLocationUpdatesAutomatically = NO showsBackgroundLocationIndicator = YES allowsBackgroundLocationUpdates = YES activityType = CLActivityTypeOtherNavigation UIBackgroundModes includes "location" (verified at runtime)

This matches the settings described as compliant in threads 726945 and 776698 regarding the iOS 16.4 change.

Ruled out with logs: the app never stops the session; no app-side filter runs during the gaps; no crash or memory kill (same process before and after); queue length under 20 and handler time ~3 ms. Tested BestForNavigation + 5 m filter, Best + no filter, and BestForNavigation

no filter — all three show gaps, the last is best but not cured.

Two observations that may matter: immediately after each gap the first fixes have horizontal accuracy of 170-1950 m, consistent with a cold session start rather than a resume. And on one occasion a foreground watcher callback delivered a fix 264 seconds old on resume.

Questions:

Under what conditions does iOS 27 suspend an app with an active standard location session configured this way?
Does calling startMonitoringSignificantLocationChanges alongside startUpdatingLocation affect suspension behaviour?
Is CLBackgroundActivitySession or CLLocationUpdate.liveUpdates the supported path for sustained background recording on iOS 17+?
Can an app detect that its session has been suspended, so it can report honestly to the user?

Answer 1

DTS Engineer OP

Apple

1d

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

Answer 2

wildnx OP

6h

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.