Hi Ed, Thank you for confirming that the native animation APIs are effectively non-interruptible. This validation saves us from chasing a "magic configuration" that doesn't exist. Sharing a bit about our use cases that the user must be able to interrupt the route preview immediately (e.g., to pan or zoom while the camera is moving on for example, 10 seconds of zooming). Regarding the performance spikes I mentioned: We have already implemented several optimizations to mitigate the 120Hz/8.33ms constraint you highlighted: Capping Frame Rate: We set preferredFrameRateRange to target 30-45 FPS (avoiding the 120Hz ProMotion tax) to reduce the workload and changed it depends on the device spec, how "close" or "far" is the zooming. Visual Thresholds: We try to skip rendering frames during CADisplayLink ticking with some threshold. Even with these "throttles" in place, simply calling setVisibleMapRect(..., animated: false) 30 times a second drives CPU usage to 80-100% on the simulator, likely due to the heavy vector tile re-calculations in the MKMapView internals. Is there a specific "Golden Path" or workaround for interruptible camera movement that we are missing? For example: Is there a way to update the camera model without forcing a full immediate tile layout pass every frame? Alternatively, is there any obscure trick (like a specific RunLoop mode or UIViewPropertyAnimator state manipulation) that can successfully cancel a native setCamera(animated: true) flight without dropping the user's touch? We are trying to achieve the standard "Navigation Mode" behavior seen in Apple Maps (where the camera moves but the user can grab it instantly), but using public APIs. We try to figure this out because we benchmark on the Maps app itself when we recenter, we can interrupt the recenter process, as we think this is also can be implemented internally using MapKit Thanks again for your insight!