I have made a Feedback request to not deprecate the method. It is difficult for an app to parallel a set of UNNotificationRequest's set at various times and determine what badge number those requests may have set. It can be done, but what a hassle!

And again - shouldBadge in CloudKit, if ever set to YES, will permanently screw up the use of CloudKit as far as the app's badge is concerned. BIG mistake on your part. Please restore some method of zeroing that count and eliminate shouldBadge.

So the shouldBadge function in CloudKit increments a badge that is permanent and gets set as the app icon's badge whenever CloudKit sends a new notification. Over and over again. And there is no way of zeroing or clearing that badge count. Either I don't understand what you did or you don't understand what you did. PLEASER explain!

I got the single target app to work by implementing "getComplicationDescriptors(handler:)" and deleting the plist entry for "ClockKit Complication - Supported Families". (I think that's equivalent to changing the CLKComplicationDescriptors as suggested above). But because of the cache issue, the user still needs to edit the available complications on the watch face and chose the new one - but that may be self evident when the user sees "---" on the watch face.

I again had this problem and searched and found my solution from 3 years ago - thank you/me.

Please change "the value in the info.plist" to "the value in the Entitlements File"