Post

Replies

Boosts

Views

Activity

Reply to Title: Background location deliveries stop after 2-5 minutes on iOS 27 despite guidance-compliant configuration
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.
6h
Reply to Title: Background location deliveries stop after 2-5 minutes on iOS 27 despite guidance-compliant configuration
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.
Replies
Boosts
Views
Activity
6h