错误检查：CloudKit MacCatalyst didReceiveRemoteNotification

我正在使用 MacCatalyst 将 iOS/iPadOS 应用程序移植到 MacOS。该应用程序以所有方式使用 CloudKit 和功能，除了以下一种方式：UIApplicationDelegate方法，didReceiveRemoteNotification，当从其他设备提交 CloudKit 更新时，不会在 MacOS 版本上调用

应用程序中有效的功能：

• 正在提交CKDatabaseOperation包括 CloudKit 的更新和订阅
• 从 CloudKit 手动检索数据库更新
• UIApplicationDelegate method didRegisterForRemoteNotificationsWithDeviceToken火灾和UIApplication.isRegisteredForRemoteNotifications调用时返回trueUIApplication.registerForRemoteNotifications
• 设置CKSubscription.NotificationInfo调用在 MacOS 中正确显示的警报通知
• UNUserNotificationCenterDelegate方法，willPresent，当调用警报通知并且应用程序位于前台时
• didReceiveRemoteNotification在 iOS 和 iPad（物理设备）上

有没有人有过UIApplicationDelegate方法，didReceiveRemoteNotification，在使用 MacCatalyst 时调用？

更新： 该应用程序最终确实触发了didReceiveRemoteNotification发送更新后 30 分钟后调用该方法，但对于其他更新，即使在几小时后也不会触发该方法。有任何想法吗？

我有一个可能的解决方案，尽管我看到的问题与您描述的略有不同。这是快速版本：至少使用.userInitiated qualityOfService在催化剂上。

这就是我认为正在发生的事情。

CKOperation.h 提供了此文档：

@discussion CKOperations behave differently depending on how you set qualityOfService.
 *
 *  @code
 *  Quality of Service | timeoutIntervalForResource | Network Error Behavior | Discretionary Behavior
 *  -------------------+----------------------------+------------------------+-----------------------
 *  UserInteractive    | -1 (no enforcement)        | fail                   | nonDiscretionary
 *  UserInitiated      | -1 (no enforcement)        | fail                   | nonDiscretionary
 *  Default            | 1 week                     | fail                   | discretionary when app backgrounded
 *  Utility            | 1 week                     | internally retried     | discretionary when app backgrounded
 *  Background         | 1 week                     | internally retried     | discretionary
 *  @endcode
 * timeoutIntervalForResource
 * - the timeout interval for any network resources retrieved by this operation
 * - this can be overridden via CKOperationConfiguration's timeoutIntervalForResource property
 *
 * Network Error Behavior
 * - when a network request in service of a CKOperation fails due to a networking error, the operation may fail with that error, or internally retry the network request.  Only a subset of networking errors are retried, and limiting factors such as timeoutIntervalForResource are still applicable.
 *
 * Discretionary Behavior
 * - network requests in service of a CKOperation may be marked as discretionary
 * - discretionary network requests are scheduled at the description of the system for optimal performance
 *
 * CKOperations have a default qualityOfService of Default.

请注意，默认的自由裁量行为是“应用程序后台运行时的自由裁量”，并且自由裁量行为的描述表示“自由裁量网络请求在系统的[自由裁量]上进行调度，以获得最佳性能”。我认为这就是 Catalyst 中正在发生的事情；如果应用程序不在前台，则请求将变得可自由裁量——即可推迟。而且，就我而言，延期似乎是无限期的。

这就是我所看到的。

• 我在 iPhone 上启动了该应用程序
• 我在 Mac 上启动了该应用程序
• 我将 Mac 应用程序置于“后台”（即，它不再处于活动状态）
• 我在 iPhone 上进行了更改
• Mac 收到远程通知
• 为了响应远程通知，Mac 尝试下载（获取）记录
• 下载请求从未完成

这就是我所做的。

我已经分配了一个CKOperationGroup https://developer.apple.com/documentation/cloudkit/ckoperationgroup致我所有的CKOperation https://developer.apple.com/documentation/cloudkit/ckoperations，并且我已经分配了一个值defaultConfiguration.qualityOfService。在 Catalyst 上我改变了一些东西，以便最小化qualityOfService我分配的是.userInitiated。这使得问题在测试中消失了。 （需要明确的是，我尝试了很多方法；这是唯一有效的方法。）我昨晚将一个版本投入生产，并且 - 至少到目前为止 - 我也不再看到那里的问题。

如果你不使用CKOperationGroup https://developer.apple.com/documentation/cloudkit/ckoperationgroups，不用担心，您可以设置qualityOfService直接在CKOperation https://developer.apple.com/documentation/cloudkit/ckoperations;这应该同样有效，只是不完全是我所做的。

我通过反馈向 Apple 提交了错误。