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.
Post not yet marked as solved
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);
Post not yet marked as solved
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.
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?
Post not yet marked as solved
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.
Post not yet marked as solved
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.
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.
"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?
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.
Post not yet marked as solved
I think this must have been a seaparate issue particular to your code. To know for sure, can you test whether or not, when you choose "Save Image" option from the share sheet (using iOS 13) your view controller gets dismissed at same time as share sheet is dismissed, immediately after save, whereas your own view controller doesn't get dimissed (i.e. just share sheet gets dismissed, as expected) when you choose any other share option?
Post not yet marked as solved
Same here. Other share actions seem to leave the presenting view controller in place - only the Save Image function leads to dismissal. Testing on iOS 11.2 and iOS12.0 shows it doesn't happen there. Must surely be an OS bug introduced in iOS13. Couldn't find any way to trap it or prevent it in my own code. Unfortunately I have users who are annoyed by this behaviour as it interrupts their workflow with the app. Would love a workaround if anyone can find one.
