I assume KMT's answer is satire. Lol. Of course Apple specifically URGED developers to download the GM version so that we could submit our app updates in time for iOS14 public release.

"Pick one process and stick with it." - I wish it was that simple. Apple's developer website simply points to MAS for non-beta releases. But of course betas are not available from MAS, so had to download and update these from the developer site. So, KMT, unfortunately your answer is just not realistic, and in any case doesn't address the specific situation I (and I am sure many others) are currently in. Further information: 1) The Apple developer site now points downloads of current Xcode version (12A7209) to MAS - so it is indeed the same build as Apple provided as GM, and that I had already installed. 2) When I let the MAS proceed with its update of Xcode, it downloads the entire update but then immediately fails with a message "Xcode could not be installed. Please try again later.". So my question still stands. How to rectify this situation?

Based on answers given here, this is how I resolved this issue: Note - I had previous renamed the Xcode.app to Xcode11.app before I downloaded Xcode 12 GM from Apple developer site, knowing that once unxipped it would want to name itself Xcode.app. After doing this, apparently Mac App Store was still pointing to the Xcode11.app file as the one it "owns". Made a copy of the old Xcode11.app and named the copy Xcode11p7.app (in case I need to use the old version again sometime) Deleted the Xcode11.app file - this immediately caused Mac App Store to remove its update prompt for Xcode In future, I will only download Xcode versions and updates from Apple Developer site.

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.