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?

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.

Alternatively, click on the .xcodeproj file. Then in the main menu, click View -> Hide code review