Post

Replies

Boosts

Views

Activity

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