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!
To understand whether your strategy as a whole is right, I would need to know more about the user experience you're trying to achieve. Depending on what you're trying to accomplish, there might or might not be a more efficient or privacy-preserving alternative?
To the specific question of whether you should funnel everything through one CLLocationManager, there is no requirement that you do so. If you want to coordinate the various needs of your app into a single CLLocationManager configuration, you can, but you could also dedicate CLLocationManagers to different needs you have.
CLLocationUpdate and CLMonitor are designed to be used in the latter way: with eg each part of your app that needs updates iterating them independently as needed.
