Thanks for the comments. Yes, I do call UNUserNotificationCenter's requestAuthorizationWithOptions (with alert and sound, but not badge), and if granted, I call registerForRemoteNotifications. The didRegisterForRemoteNotificationsWithDeviceToken is also called. The CloudKit dashboard shows that a push notification is generated. As I mentioned, even the iPhone's console logs seem to show that Springboard receives the notification ... it shows "Received remote notification request 0E01-5E4D [ waking: 0, hasAlertContent: 0, hasSound: 0 hasBadge: 0 hasContentAvailable: 1 hasMutableContent: 0 pushType: Alert]"... but it just doesn't seem to pass it forward to the app. It says "NOT delivering non-notifying push notification 0E01-5E4D [pushType: Alert willNotifyUser: 0]"Strangely, it works fine on the Mac app, which is pointing to the same private CloudKit database and uses the same CloudKit subscription. Any thoughts? Could app signing have anything to do with this? I do have the CloudKit and Push Notifications capabilities enabled in the Xcode project file, but I generate manual provisioning profiles for the iOS app vs automatic provisioning for the Mac app. But the profiles are valid for "Development" when I'm testing this.
zstesting
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
Turns out, it was an iOS13 problem, and wasn't working on the Release version either. Apparently, Apple changed the behavior so that when you setup a CKSubscription, the CKNotificationInfo's alertBody property should be nil, instead of an empty string, which is what you needed to do to get notifications to work before. I did have to recreate the subscription, but it works now. Even the device console now shows this:Received remote notification request DB7E-4D9E [ waking: 0, hasAlertContent: 0, hasSound: 0 hasBadge: 0 hasContentAvailable: 1 hasMutableContent: 0 pushType: Background]
Process delivery of push notification DB7E-4D9E
Request DUET delivers content-available push notification to applicationAnd then the app's didReceiveRemoteNotification (finally) gets called!
yes, it's meant to be a silent notification.