Is activityType isolated between CLLocationManager and CLLocationUpdate.liveUpdates?

Update with the current evidence and diagnostic sample:

The historical observation occurred in Gwacheon in April 2025. I was driving on a newly opened eastbound road that was not shown in Apple Maps at the time; this was not generic off-road driving. With a delegate-based CLLocationManager (V1) using .other and CLLocationUpdate.liveUpdates(_:) (V2) using .otherNavigation, V2 sometimes bent south toward an older mapped road only while V1 was running concurrently. Two independent CLLocationManager instances (V1 + V1) remained independent.

I did not collect raw logs when this occurred. The annotated image in the original post illustrates the historical path but is not a raw location log. I can no longer reproduce the behavior at Gwacheon or Osan. The underlying Apple map data may have been updated, but I cannot confirm that.

I updated LocationActivityTypeBugSample. It can run V1 + V1 or V1 + V2 with a separate activity type for each source. During a session, it marks Source 1 and Source 2 on an Apple Map using distinct S1 and S2 markers labeled with the selected V1/V2 API. It also exports source-tagged logs with timestamp, latitude, longitude, accuracy, device model, and OS version.

I am providing the sample project directly to Apple DTS with this forum link. The sample does not reproduce the April 2025 map-matching behavior by itself; it is intended to compare the two concurrent sources in real time.

My questions remain:

1. Is activityType expected to remain fully isolated between CLLocationManager and CLLocationUpdate.liveUpdates(_:) when they run concurrently?
2. If I find a newly opened road where the problem reproduces, which diagnostics should I collect?

However, while V1 is running, V2 sometimes reports coordinates with a southward bend that appears aligned with a nearby mapped road. This occurs when traveling off-road beside that road.

Please file a bug on this and post the bug number back here. What's going on here is that CLLocationUpdate's internal implementation isn't entirely isolated, which means the configuration outside of it can modify it's behavior.

I'm slightly surprised by the details to the particular case you've described, but if you'd run the same test with two CLLocationUpdate object and more divergent activityTypes (for example, CLActivityType.automotiveNavigation and CLActivityType.fitness), I think you'd find that the disruption is fairly obvious. Related to the point:

I did not collect raw logs when this occurred. The annotated image in the original post illustrates the historical path but is not a raw location log. I can no longer reproduce the behavior at Gwacheon or Osan.

The activity types you're using are close enough to each other that this PARTICULAR divergence is no longer occurring, however, that isn't doesn't mean the underlying issue hand changed.

Is activityType expected to remain fully isolated between CLLocationManager and CLLocationUpdate.liveUpdates(_:) when they run concurrently?

I'm not sure what the final resolution will be, but we need to either improve CLLocationUpdate's isolation or document that that they should be used as a singleton. The particular case you're seeing is slightly odd, but the reality is that if you want to monitor multiple activity right now, you should use CLLocationManager.

If I find a newly opened road where the problem reproduces, which diagnostics should I collect?

The basic information is a coordinate list from both data stream, a general description of what happened, and a sysdiagnose from the device that experienced the issue. If you're device is setup in advance, then a sysdiagnose with the "Location Services" profile installed would certainly be helpful.

However, a few things I want to clarify:

• It's expected that the coordinates returned by different activity types will vary. Notably, road binding is tied to activity type.

• The actual bug here would create a tendency for coordinates to converge, as one update object ends up returning the configuration of the other.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware