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

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.

Any news on this matter?

Tybion, were you able to provide them a project? If needed, I can prepare something for you.

Or are Apple already working on this bug, and therefore this (submitting a demo project) would all be a waste of time, just duplicating effort?

Likely this, I would say.

I was serious in my previous comment that other mapping solutions are available.

Consider this: if you had started implementing Google Maps, or MapBox, or ArcGIS, or AWS maps, when you first became aware of this, would you have completed that work by now? Of course cost is a consideration for most of these, but you could maybe consider this a temporary cost until Apple implement a fix. What’s it worth to keep your users happy?

Thanks for the offer, Emre. I have pushed my support call as far as I can now, so will need to close it. Do you still have one of your two annual free support calls to Apple, so you can open a call yourself?

I think I have solved the immediate problem for my customers, which involves losing styling, but the top priority was getting the app working again.

Might be helpful to others to give a little detail ..

I tried 2 variants of the following code with 2 testFlight users, but this created other problems, and the app was still freezing, so it was not a solution.

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

My app records and plots users trails as they walk/drive in remote country. I had data from my 2 testers. Fortunately, when I was testing with only 200 trails, I noticed one line in the log saying 'Map has 2284 overlays'. The simplified code is below - it might be useful for others to put this in appropriate places in your code.

print("Map has \(myMapView.overlays.count) overlays")

This occurred because the walking pace segments of each trail are green, and the faster parts are red - each segment being in its own MKPolyline. The fix was to get rid of the colour-coding, so there are now only about 200 overlays. To reinstate the colour-coding, presumably I could hold all the green segments for a trail in one MKMultiPolyline, and all the red segments in another MKMultiPolyline? Then there would only be 2 MKMultiPolylines per trail. Yet to test.

Note that this test data is small compared to what customers used to handle prior to iOS 16. When this customer originally contacted me about 'app freezing' I asked her how many trails she had, and she basically answered 'very few - I have deleted most of my trails now to try to fix the problem'.

Some numbers - my main tester has 18,400 vertices in 171 trails, but this number would have been many times larger before she pruned her trails. Another customer that supplied his trails to me had 140,000 vertices in his trails (and this was fine prior to iOS 16). Note than when I reduced the number of MKPolylines from 2284 to 171 the number of vertices remained unchanged, so the problem in iOS 16 seems to be more about the number of MKPolylines/MKMultiPolylines than the number of vertices.

I just did some testing on the iOS 16.4 Beta and it seems to be a lot better. Have not been able to replicate it at least! 🎉

Looks like iOS 16.4 Beta 1 solved the performance issue with drawing on MKTileOverlay. Looks like a few performance issues might have been solved. Hopefully is stays this way.