I'm repeatedly getting this error on one - but not all - CKQuery operation:CKError(_nsError: <CKError 0x608000846ff0: "Service Unavailable" (6/2022); "Request failed with http status code 503">)There's no further useful info in the UserInfo dictionary, including no value for the CKErrorRetryAfterKey.My code initially queries CloudKit for basically two fields: "name" and "hash". Hash is a hash value for a CKAsset file (on the same record) that I don't want to download unless the hash code indicates that the file has changed.For all the records whose hash codes indicate that I should download the CKAsset, I prepare the same query in the same code, but add the "json" field and rerun, to download only the json files that I need. I use this predicate, containing an array of the desired CKReferences NSPredicate.init(format: "recordID in %@", fullRecordsToDownload)The first query always works, the second always fails with the 503. Every time I repeat, it's the same pattern.Thus it can't really be that the service is unavailable, right?How can I diagnose this?

In my iOS app, I check to see if there's an active complication before sending complication data to the watch, given the limit of 50 transfers per day. It seems isComplicationEnabled() always returns false in the simulator, even though I have a watch app in a watchOS simulator that's active and running, with complications that actively get updated from the watch code as well. Data is successfully being passed from the simulated iPhone to the simulated watch app - both are active, connected and otherwise in sync. When I run using a physical device, WCSession isComplicationEnabled() on my iPhone does return true, but it seems to always be false in the simulator. Is this a limitation? Bug? Anyone else seeing this?

What specifically does it mean when the WCSession activationState == activated? I had originally thought it meant the iOS app would be able to communicate with the paired watch, but I'm seeing the activationState set to activated even when the paired watch is powered off or otherwise inaccessible. If it means iOS can reach some paired watch, but if it says nothing about whether it can do it right now, how can I tell if in fact the watch - not the companion app, the watch itself - is accessible?

My iOS app uses silent push notifications via application:didReceiveRemoteNotification:fetchCompletionHandler to trigger background refreshes. Occasionally a refresh will time out, and when the next silent notification comes in, the original process will complete. Example: SilentNotification SN1 with CompletionHandler CH1 is received A background refresh process BR1 begins, but times out SN2 later arrives, with CH2 BR1 continues now that iOS has awakened the app, and runs to completion (There's no BR2, since I'm able to detect that the BR1 is still able to be completed) Which CompletionHandler do I call? Should I hold onto CH1 and call it when the refresh completes, even though it's running in SN2's time allocation? Do I call CH2 instead? Both?