Post

Replies

Boosts

Views

Activity

Is our background location strategy correct?
Hey everyone, in our project, the architecture sets all location services through one CLLocationManager, configured for navigation accuracy with background updates enabled. Start/stop is condition driven, so we track location while navigating, free-driving, connected to CarPlay or to a BLE device and stop immediately (no timeout) when none of those hold and the app is backgrounded. On stop() we tear down everything, including startMonitoringSignificantLocationChanges . BLE Device connection forces full background location for as long as it's paired and requires “Always authorization”. We keep one continuously-updating CLLocationManager (navigation accuracy, no distance filter, no auto pause) alive in the background whenever we're navigating, free-driving, connected to CarPlay, or to a BLE device using a CLBackgroundActivitySession on iOS 17+. Is a single always-best-accuracy manager the right approach, or should we be downgrading accuracy / using pausesLocationUpdatesAutomatically in some states for battery or performance? Any pitfalls with CLBackgroundActivitySession lifecycle we should watch for? As I wrote above, when the BLE accessory connects we force full background location on for the entire duration it's paired, and we require “Always authorization” for the BLE link to survive backgrounding. Is keeping location running the whole time an accessory is connected the right model? Thanks for the opportunity and have a great day!
1
0
77
23h
Is our background location strategy correct?
Hey everyone, in our project, the architecture sets all location services through one CLLocationManager, configured for navigation accuracy with background updates enabled. Start/stop is condition driven, so we track location while navigating, free-driving, connected to CarPlay or to a BLE device and stop immediately (no timeout) when none of those hold and the app is backgrounded. On stop() we tear down everything, including startMonitoringSignificantLocationChanges . BLE Device connection forces full background location for as long as it's paired and requires “Always authorization”. We keep one continuously-updating CLLocationManager (navigation accuracy, no distance filter, no auto pause) alive in the background whenever we're navigating, free-driving, connected to CarPlay, or to a BLE device using a CLBackgroundActivitySession on iOS 17+. Is a single always-best-accuracy manager the right approach, or should we be downgrading accuracy / using pausesLocationUpdatesAutomatically in some states for battery or performance? Any pitfalls with CLBackgroundActivitySession lifecycle we should watch for? As I wrote above, when the BLE accessory connects we force full background location on for the entire duration it's paired, and we require “Always authorization” for the BLE link to survive backgrounding. Is keeping location running the whole time an accessory is connected the right model? Thanks for the opportunity and have a great day!
Replies
1
Boosts
0
Views
77
Activity
23h