UIKit - Stop ongoing animation on the extended setVisibleMapRect Animation time on MapKit

There is a good example of animating a map using MKMapCamera in our Look Around sample code project. Using the map camera gives you better control over writing your own animation sequences, as the animations provided by setting the animation parameter of setVisibleMapRect to true will be decided by the system. However, as you found, those animations are effectively non-interruptible in practice due to how MapKit manages animations, regardless if you use the UIView family of animation methods, or UIViewPropertyAnimator. Enhancement requests for better integration across the animation APIs are welcomed!

I've tried using CADisplayLink to manually animate the camera per system fresh rate, it works very well, I can stop the camera movement anytime there are touches, but it causes the resource CPU spikes.

While you can use CADisplayLink to control rendering of any UIView on a frame-by-frame basis, you have to keep in mind the stringent performance targets you need to hit in order to not introduce perceivable frame drops. CADisplayLink runs at the display refresh rate, so on devices with a ProMotion display, the display refreshes at 120 Hz, or 120 times every 1,000 milliseconds. That means you have 8.33 ms to render every frame. This can be very difficult to get right, and means you have to be extremely diligent about deferring any non-essential work off the main thread to make sure your main thread can hit those deadlines, so in general, I don't suggest taking this approach due to the difficulty of pulling it off well. I can't comment directly on the CPU spikes directly since it's been some time since I last looked at doing something like this, but I hope your experiences discovering details like that illustrates why this requires detailed engineering diligence to maintain performance.

Removing the animation layers recursively on sublayers and subviews also doesn't help.

In general, you should avoid tinkering with the subviews or sublayers of any views other than your own.

— Ed Ford,  DTS Engineer

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!

Is there a specific "Golden Path" or workaround for interruptible camera movement that we are missing?

There aren't any that I'm aware of, and there also aren't any real tricks I can provide around things like RunLoop modes or UIViewPropertyAnimator that will help get you to your goal in any supported fashion either.

Regarding the performance spikes I mentioned: We have already implemented several optimizations to mitigate the 120Hz/8.33ms constraint you highlighted: [...] 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.

I last experimented with the CADisplayLink path with MapKit several years ago, and it was difficult to do well even then. In the time since, the visual detail displayed by MapKit has increased significantly, and ProMotion displays are on many more devices, where as I had only 60Hz timing to worry about back then, and not 120Hz. I'm glad to hear about your experiments trying to push the limits of what's possible here, but I'm certainly not surprised at what you discovered based on my own explorations in the past. That past experience of mine is what underpins why I don't really recommend this approach.

As I said, we welcome enhancement requests to help you meet your goals.

— Ed Ford,  DTS Engineer

Thanks a lot for your detailed answers, it helps unblocking our confusion. I've shared some enhancement requests to through the Feedback Assistant hopefully we can get things done.