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: Is activityType expected to remain fully isolated between CLLocationManager and CLLocationUpdate.liveUpdates(_:) when they run concurrently? If I find a newly opened road where the problem reproduces, which diagnostics should I collect?

AppleLocationCrashLog.crash or https://github.com/steve-ham/AppleLocationCrash/blob/main/AppleLocationCrash/AppleLocationCrashLog.crash Thanks for answering. I'm not accessing the variable after setting it to nil. Here’s the log: When CLBackgroundActivitySession deallocates in any form without an explicit call to invalidate, the crash occurs after reproducing the steps following step 5. The documentation does not mention this, and WWDC guidance suggests calling invalidate OR destroy to end the session (but destroy causes a crash): The crash originates from Apple’s thread and ChatGPT thinks it's memory management issue for Apple's Core Location team: Thread 1 name: Dispatch queue: com.apple.corelocation.shared Thread 1 Crashed: 0 libobjc.A.dylib 0x186c2e870 objc_release_x8 + 16 1 libsystem_blocks.dylib 0x211e6d860 bool HelperBase<ExtendedInline>::disposeCapture<(HelperBase<ExtendedInline>::BlockCaptureKind)3>(unsigned int, unsigned char*) + 67 2 libsystem_blocks.dylib 0x211e6d570 HelperBase<GenericInline>::destroyBlock(Block_layout*, bool, unsigned char*) + 159 3 libsystem_blocks.dylib 0x211e6d030 _call_dispose_helpers_excp + 71 4 libsystem_blocks.dylib 0x211e6cfcc _Block_release + 255 5 libsystem_blocks.dylib 0x211e6ce90 bool HelperBase<ExtendedInline>::disposeCapture<(HelperBase<ExtendedInline>::BlockCaptureKind)4>(unsigned int, unsigned char*) + 67 6 libsystem_blocks.dylib 0x211e6d584 HelperBase<GenericInline>::destroyBlock(Block_layout*, bool, unsigned char*) + 179 7 libsystem_blocks.dylib 0x211e6d030 _call_dispose_helpers_excp + 71 8 libsystem_blocks.dylib 0x211e6cfcc _Block_release + 255 9 libdispatch.dylib 0x1916460d0 _dispatch_client_callout + 19 10 libdispatch.dylib 0x19164d6d8 _dispatch_lane_serial_drain + 743 11 libdispatch.dylib 0x19164e1e0 _dispatch_lane_invoke + 379 12 libdispatch.dylib 0x191659258 _dispatch_root_queue_drain_deferred_wlh + 287 13 libdispatch.dylib 0x191658aa4 _dispatch_workloop_worker_thread + 539 14 libsystem_pthread.dylib 0x211e73c7c _pthread_wqthread + 287 15 libsystem_pthread.dylib 0x211e70488 start_wqthread + 7

I'm having the same problem.

Thanks for replies! @endecotp I guess I'm through more often than not. However, yea, it may be inefficient time usage in some cases. I think it's individual's call/perspective/interpretation. My colleague found an app (GPS Diagnostic: Satellite Test.) that shows satellite count in the App Store screenshot: https://apps.apple.com/us/app/gps-diagnostic-satellite-test/id1020967894?platform=iPhone I agree that Apple API (even low level) doesn't provide satellite count directly. I guess that developer found the count indirectly. I'll email that developer asking broadly how he got the satellite count. If someone can guess how that developer got the satellite count, for example by using some kind of signal strength that would be helpful for me and people who see this post I think. If I get email replied back from the developer. I'll submit a thread here also.

Getting import CocoaPod error if I do below, still debugging s.pod_target_xcconfig = { 'EXCLUDED_ARCHS' => 'arm64' } s.user_target_xcconfig = { 'EXCLUDED_ARCHS' => 'arm64' }

Found an answer of not building on iPhone Simulator with M1 MacBook: For building App. A. MyProject -> TARGETS -> MyProject -> Build Settings -> Excluded Architectures -> Add arm64 B. Pods -> PROJECT -> Pods -> Build Settings -> Excluded Architectures -> Add arm64 For building CocoaPods library. Add below in podspec. s.pod_target_xcconfig = { 'EXCLUDED_ARCHS' => 'arm64' } s.user_target_xcconfig = { 'EXCLUDED_ARCHS' => 'arm64' }

Strangely if I install 'LibTorch-Lite' with 'OpenCV' https://github.com/pytorch/ios-demo-app/tree/master/HelloWorld runs on simulator too. platform :ios, '12.0' target 'HelloWorld' do pod 'LibTorch-Lite' pod 'OpenCV' end

Me too, I'm having the same problem. LibTorch is not installing as CocoaPods dependency with MacBook M1. Can someone who found an answer to this please write a reply? Thanks.