Drawing MKPolylines on map make app unresponsive. Anybody else have this problem ?

Seems that we always get this before the crash:

[VKDefault] Exceeded Metal Buffer threshold of 50000 with a count of 51635 resources, pruning resources now (Time since last prune:31.189292): Assertion with expression - false : Failed in file - /Library/Caches/com.apple.xbs/Sources/VectorKit/src/MDMapEngine.mm line - 1363

To be even more precise, this issue started with iOS 16.1.

Same problem on iOS 16 with MapKit and overlays. After some moving/zooming in-out app hags and crashes with console log

`[VKDefault] Exceeded Metal Buffer threshold of 50000 with a count of 51809 resources, pruning resources now (Time since last prune:113742.196925): Assertion with expression - false : Failed in file - /Library/Caches/com.apple.xbs/Sources/VectorKit/src/MDMapEngine.mm line - 1363

Same issue, but seems to only affect iOS 16.1. Happens after zooming and panning around a map with many MKPolylines and MKPolygons

[VKDefault] Exceeded Metal Buffer threshold of 50000 with a count of 59670 resources, pruning resources now (Time since last prune:21.620829): Assertion with expression - false : Failed in file - /Library/Caches/com.apple.xbs/Sources/VectorKit/src/MDMapEngine.mm line - 1363

Filed an issue for this: FB11774719

Important: After some more investigating, to be more precise, this issues seems to be popping up as of 16.1.

This issues seems to have started with 16.1.

 many MKPolylines and MKPolygons

By "many", do you mean thousands or millions? Are they all visible, or are many of them off-screen? How does the number of lines or points compare with the 50000 number in the error message?

I'm posting this workaround that we found and implemented in our project. The work around for us until apple fixes the issue is after the call to .addOverlay of the polylines we do (our map is on .standard normally):

mapView.mapType = MKMapType.hybrid mapView.mapType = MKMapType.standard

The switch is not perceivable, but makes the map flicker a little, but more importantly it seems it clears the app cache and stops the whole map and app from freezing.

See source: https://stackoverflow.com/questions/69248520/vkdefault-triangulator-failed-to-fully-triangulate-polygon-mapkit

For the beefier numbers of polylines we had to reduce the number being added as even with the workaround some big numbers were still creating freezes.

We are having the same issue. We use iOS 16.1 (not sure if it happens with iOS 16.0).

We have a micromobility (scooter rental) app and we have mkpolygons there. After zooming in and zooming out couple of times, console prints this error of exceeding metal buffer threshold and then app gets completely unresponsive. It is not crashing, but it gets frozen and user has no option other than to kill the app. We found out that setting mapType to something else (i.e. satellite) and then back to standard solves the issue as it clears mapView's cache. However, that creates massive flickering issue and we don't want to create another issue for solution to another.

Did you come up with anything or are you still waiting solution?

Same problem here, our mission planning app (with MKpolylines on the map) now get non-responsive with iOS16.1 while editing the mission. Anyone found a solution that is not changing mapstyle?

It seems as the problem might be related to the number of MKOverlayRenderers making draw calls. Using MKMultiPolyline/Polygon seems to be a workaround but that does not work if you need to support iOS 12 or style the lines and polygons differently.

I'm getting this very quickly in areas that require a lot of MKPolylineRenderer / MKPolygonRenderer / MKMultiPolygonRenderer. I have tried changing mapType on when moving about, before removing/adding new overlays, but it's just totally flaking out on iOS 16.1.1. This is kind of a critical issue for us as it's breaking our production application. Has anyone got any insight into this this recently?

iOS 16.1.2 didn't fix this issue, I was wondering about the betas if anyone has tried. Would be interesting to know apple guidance about this, should we just wait for a fix at o/s level and avoid any complex rendering in the meantime ? I had to disable some of the features when my app is running on iOS16, users were complaining about freezes.

Would be interesting to know apple guidance about this

Apple don't comment on their future plans, including their future plans regarding fixing bugs.

I had to disable some of the features when my app is running on iOS16

That's a good approach, but beware, you need to be careful about what you put in the "what's new" information in App Store Connect.

The alternative is to replace MKMapKit with something else, where there is more responsive upstream support, where you can fix bugs yourself if necessary, and where you are in control of when it is upgraded to new versions.

No solution to offer, but we acknowledge the issue - we have thousands of app freezes for iOS 16.1+ for our app. Minimizing the number of polylines seems to circumvent the issue, but it removes some functionality for us.

For now this is an ios16 problem. Make your maps "flat" and not "realistic" and your application will stop freezing or crashing.

I can report that iOS 16.2 RC does not fix the issue unfortunately. Swapping mapType to something else and then back when the user moves the map is the only relatively stable workaround we have found, even though it makes the map flash a bit.

Experienced the same issue as the ones mentioned before: MKMapView becoming unresponsive when adding overlays. Amount of overlays wasn't silly high which is sort of irrelevant anyway because iOS < 16 handled them well.

Just found a solution: instead of adding your MKPolylines one at a time each with its own renderer, create a MKMultiPolyline instance and add that as an overlay. Change your renderer from MKPolylineRenderer to a MKMultiPolylineRenderer.

Warning: this only works if your MKPolylines can be the same color, thickness etc. If you want one MKPolyline to be red and another green, you still need to create them as single instances each with their own renderer to take care of style.

Consider the MKMultiPolyline and MKMultiPolylineRenderer solution as something that only works for polylines that need to be rendered in the same way. You sort of group those in a multi instance using a single renderer.

On iOS 16.3 Beta 1 this is still an issue

To workaround I've reduced the number of polylines, from about a hundred to less than 5, but now I can't color each segment as desired... But, in my case, better user experience than map flickering

Using the 3D map style I have gave me less problems (or no problems) but that style is not good for my app

I wonder if apple is aware of the problem, until iOS 16.0 everything was fine

I’m experiencing the same issue. As suggested earlier, switching to MKMultiPolyline helps, but it is not a proper solution and results in losing functionality of my app…

As a side note: it seems that the issue only occurs iOS 16.2 but not on iPadOS 16.2

Out of curiosity, how many of you are doing some form of removal and re-adding of overlays/annotations depending on zoom level?

Considering that Apple does not show any sign of working on this problem, I put in a support call to Apple myself.

After I explained that this a MAJOR problem in iOS 16.1.1+ probably affecting ALL apps using MKPolyline and MKPolypons, and gave them a link to this discussion (which they didn't acknowledge in their reply), I got an email including this ..

Please send us the following:

**A focused Xcode project that builds and demonstrates the issue.**
Ideally, this will be a new Xcode project created specifically to demonstrate this issue and which includes only the minimal code and API necessary to reproduce the issue. This focuses on the important code paths and may require you to perform additional debugging to extract the relevant code. Please do not include any 3rd-party code or frameworks unless they are absolutely required for this targeted sample project to run.

**Explicit steps to reproduce the issue.**
These steps should be everything we need to do to see the issue.

This is problematic for me, as my app is relatively complex, has a number of external dependencies, and requires a lot of user steps to set it up for a test - so Apple would not be happy to test with my app. I am a 1-man business so don't have the resources to work with Apple with their very stringent requirements.

Does anyone have a fairly simple app that has a well-defined sequence of steps to produce the problem? Or any other ideas on how to leverage this email? Or are Apple already working on this bug, and therefore this would all be a waste of time, just duplicating effort?

I might have a related FB to this issue, or more related to iOS 16 MKMapKit performance degradation when it comes to overlays that need to draw. It's "iOS 16 regression - MKMapView flicker with MKTileOverlay and MKOverlayRenderer with draw().". I have FB FB11805267 with the sample project that reproduces the issue. I used "Ask Apple" and I got confirmed that issue is known and is assigned a high priority. Then I used a DTS to ask if there is a workaround (e.g. I hoped I could only provide the overlay path and will not draw) and that returned back unused. Going to add a link to this thread to my FB.