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.
Post not yet marked as solved
Thanks for posting the fruits of your labours! I'm still struggling with this so your sample code is very helpful.A couple of questions:1) Have you actually experienced having zero conflict versions despite document marked as being in conflict?2) What are you doing in [self saveChangesToDocument] - I assume using docsData to amend contents of myDocument,but how exactly?Unfortunately I can't recall where exactly, but somewhere it Apple docs there was a note that there is a possiblity that the document conflict could be resolved in another instance of your app *before* you have a chance to complete the conflict resolution in your current instance. Do you have any thoughts on whether that is actually something that might need additional logic to handle correctly ie. to abandon current conflict resolution of a new notification arrives that indicates no conflict exists?
Post not yet marked as solved
I'm upvoting this. I'm in a very similar situation of wanting to do my own merge to manage conflicts, so the hints here are valuable to me, but seem odd and probably not as the system was designed to work. Surely there must be a better way. I'd really like to hear some kind of confirmation or otherwise that this is the only way such a merge can be done successfully.
Although I can't find any documentation that actually states this, it appears that in watchOS4 the getNextRequestedUpdateDate simply (silently) fails to run, as a result of which if you simply recompile an older app under iOS11 your complications will now just fail.Hence if you wish to use iOS11 then you apparently now MUST implement the background refresh methods for complications. Having spent nearly two full weeks attempting to debug and work around the many glitches and major inconsistencies between how these run on actual device versus simulator, incorrrect Apple sample code and documentation and STILL not managed to get a properly working set of complications (they worked perfectly under the old model), I have to agree entirely with you that the background task implementation is an utter can of worms and to be avoided at all possible costs.Worst glitches -1) WKURLSessionRefreshBackgroundTask is NEVER called when you run the simulator. Hence you have little chocie other than to do all testing/debugging on an actual watch2) XCode support for debugging on actual watch is very flakey, often fails to attach to process. Extremely slow to start up when it does.3) WKApplicationRefreshBackgroundTask must be scheduled with "preferred" time with no precise control over when it fires, even if just for testing - I've found myself sitting 30mins and longer just waiting for a refresh to fire to test one small section of code. I can only presume (?) I've exhausted some invisible budget. Or is this some other kind of XCode or API bug?4) If instead of running WKURLSessionRefreshBackgroundTask you try to run your own asynchronous task, you risk being silently terminated, with no way to run clean-up code. In my own testing I found that after about 60 correct runs of my asynchronous task, the next several were all silently terminated, thus throwing my code into unpredicatble state and thus blocking further updates.If anyone has any comments or wants to suggest that I've got any of this wrong at all, I'd love to hear it.
Post not yet marked as solved
UPDATE:After extensive debugging I've found that the main problem seems to be that just once in a while, my task to obtain updated data for the complications is terminated prematurely. This is presumably due to a timing limit that Apple refers to as "of the order of seconds". So when there is a slow connection or other connectivity my task is being dumped without allowing any cleanup code to run.In fact I had my own download class to obtain the complications data, but now, because of these terminations, I've rewritten the code to be called in WKURLSessionRefreshBackgroundTask instead, in the hope that Apple won't terminate these prior to download completion.However, others have reported, and I find similiarly, that WKURLSessionRefreshBackgroundTask are *never* called when run in the simulator. Hence all testing must be done on actual device. To make things harder, scheduled tasks run at unpredicatble times, and often long after they are actually requested, when called on actual device. This makes testing the new code excruciatingly time consuming, as I sometimes have to wait half an hour for a scheduled background update to actually occur (and probably made worse by fact that the actual device has rate limits and budgets that may be adding to these delays).In particular see Daniel Fontes entries in this thread: https://forums.developer.apple.com/thread/52508
