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

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.