Issue Summary
Our app integrates two third-party telematics SDKs that each create their own CLLocationManager:
- Core Engine — continuous GPS, geofence monitoring, and significant location changes for trip telematics
- Radar SDK — location tracking that can enable startMonitoringVisits() (CLVisit)
When Radar visit monitoring is enabled, Core Engine experiences severe location data loss — sparse or missing didUpdateLocations callbacks during active trip recording, despite Core Engine calling startUpdatingLocation() with:
- desiredAccuracy = kCLLocationAccuracyBest
- distanceFilter = kCLDistanceFilterNone
- pausesLocationUpdatesAutomatically = false
- allowsBackgroundLocationUpdates = true
When Radar visit monitoring is disabled, Core Engine location behavior returns to normal on the same devices and iOS versions.
The issue is reproducible in field testing and is not isolated to a single iOS version.
Expected Behavior
Per our understanding of Core Location:
-
Each CLLocationManager instance should deliver delegate callbacks to its own delegate independently.
-
startMonitoringVisits() should provide visit arrival/departure events without materially degrading continuous startUpdatingLocation() on a separate CLLocationManager in the same app that is configured for high-accuracy continuous tracking.
Actual Behavior
With Radar CLVisit enabled:
-
Core Engine’s CLLocationManager receives far fewer or no didUpdateLocations callbacks during periods when continuous updates are required (e.g. active driving).
-
Telematics data is incomplete or missing.
-
Behavior is worse when the Radar SDK initializes before the Core Engine SDK.
-
Disabling startMonitoringVisits() in Radar resolves the issue without other Core Engine code changes.
Technical Notes
-
Two separate CLLocationManager instances, separate delegates.
-
Visit monitoring appears to affect app-wide location behavior, not only the manager that registered it.
-
Geofence usage across both SDKs may approach the ~20 region limit, but data loss persisted even when geofence count was within limits in our tests.
-
Issue reproduced across multiple iOS versions, not tied to a single OS release.
Request to Apple
We would appreciate guidance on the following:
- Is it expected that startMonitoringVisits() on one CLLocationManager can significantly reduce or suppress didUpdateLocations on a separate CLLocationManager configured for continuous high-accuracy tracking in the same app?
- If yes, is there documented guidance for running visit monitoring alongside continuous location in multi-SDK apps?
- Is there a recommended pattern (shared manager, ordering, capability flags, background session APIs) for multiple SDKs needing different location strategies in one process?
- Should this be treated as a bug or documentation gap?
