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?

My app generates local notifications, with attached circular images that provide a graphic state indicator. For the indicator: I use a short, wide image (aspect ratio 1:6), with the circular indicator in the middle. This technique allows the the circular image to appear properly when the notification arrives, and prevents the image from being scaled to an unwanted, unnecessarily large size when the notification is opened. With iOS 14, the images on the arriving notifications are unacceptably fuzzy (blurred, pixelated), but remain crystal clear when the notification is opened. On prior versions of iOS, the images were always crystal clear, when arriving in notification center, as well as when opened. This is obviously a change from iOS 13 to 14. Any workarounds? Anyone else experiencing this?

If an iOS app crashes in the background, silent push notifications are supposed to be able to relaunch the app, and I've seen this to be true. However, my app uses core data, so when the app re-launches in the background on a locked device, the core data resources are inaccessible until the device is unlocked. I rely on what's in core data to process the incoming data, and so updates to the Today Widget or Apple Watch complications don't occur in a timely manner. I also rely on these updates to generate local notifications and to provide responses via Siri. All of these interfaces are accessible to the user while the device is locked. But the core data is not. Am I understanding this correctly, and is this the expected behavior? Any way around it?

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?

I'm running iOS 14 on a test device, with a paired watch on watchOS 6. My app is written for minimum iOS 11, while its watch app requires watchOS 6. In testing for iOS 14, the app runs properly on the iPhone, and the watch app appears and functions properly on the paired watch. However, the complication name for my app does not appear in the list in the Watch app on iOS, or in selecting a complication in the Customize UI on the watch itself. Everything is fine with another phone/watch running iOS 13/watchOS 6 respectively. Neither the iOS nor the watch app uses anything in the beta - i.e., the complications are mostly just images, with none of the new SwiftUI capabilities. What could cause the app's name not to appear in the complications list?

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?

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?