I can confirm that, using macOS, when I create dual MKapViews with one set to MKMapTypeSatellite, and the other set to MKMapTypeSatelliteFlyover, the second one had much better image resolution for a location in Sydney, Australia. But I have no idea how consistent this would be worldwide.

MKMapTypeSatellite etc are the Obj-C constant names - the ones you list are the Swift equivalents. Also FWIW there are there are currently 353 places worldwide that are covered by Flyover imagery - mainly largish cities and a few national parks. Outside those areas the satelliteFlyover option imagery apparently just reverts to the lower resolution satellite imagery.

I'm experiencing exactly same issue right now. Tried two different browsers. Anyone know if it's an issue for everyone, or just a subset of us?

I can understand that Apple System Status page might not automatically flag certain types of faults with this service... but I find it incredible that there is apparently not even a cursory monitoring service that can recognise that there are HTTP 500 faults occurring. I need to issue an urgent app update to my users. This unacknowledged fault is causing me significant uncertainty and stress.

For expediency (and backward compatibility), you could find all occurrences of UIGraphicsBeginImageContext in your code, and add a size check just beforehand, returning early with a nil image if the size is invalid. For example: if (size.width <= 0 || size.height <= 0) { return nil; } UIGraphicsBeginImageContextWithOptions(size, NO, 0);

I found the apparent cause, by creating a new project containing the simplest possible code to try to replicate this issue, and gradually making changes to replicate specifics of the code usage in my app. It seems that creating and using a second instance of EKEventStore was the cause of the issue. In previous macOS versions this did not cause any problem, and appeared to be valid usage. However, I have apparently been able to resolve the current problem by ensuring that I create and use only a single instance of EKEventStore in my app. Although the second instance I was creating on the fly does contain all the same EKSource entities, and used to return the same calendars in a call to calendarsForEntityType, it now it does not return any calendars at all in a call to calendarsForEntityType. I would suggest that this is a bug. Perhaps EKEventStore should in future be given a shared singleton property in the API.