For discussion purposes, can you confirm if the syncing user defaults is working is happening from your iPhone to Watch P2P, or the watch is connected to infrastructure WiFi and circumventing the iPhone?

Do your messages have the time to live property set? Like facetime voip calls for example, the push would need to be delivered immediately. Wondering if the system is queuing up the messages for a later time or not. I assume any VOIP push would require immediate delivery (or phone offline) for calling purposes, just a thought to double check.

When you're testing are you connected to the debugger? If so, try the "simulate background fetch" operation too.In one of the networking videos this summer, it was stated that if the user is on low data mode (per network), all "background fetch" will be discontinued. Based on the API naming, I assume this means the same API as silent push i.e. fetchCompletionHandler.Double check the test devices are not metering their network with Low Data mode enabled.Out of curiosity, how many silent notifications are you sending per day/per user on average?

Republishing your app will not affect your push certificate. Just as the apple dev support email says, you must configure that under Certificates, Identifiers & Profiles.If you see something about keychain and requesting a certificate from an authority, you're on the right track.Here is an apple link on how to do it:https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/establishing_a_certificate-based_connection_to_apnsOtherwise there are a few quick hits on google "generate push certificate". The look and feel has been updated over the years so a few online articles may look a little dated.

The documentation for the push payload explicitly state that sending a "content-available" message with badge, alert, or sound specified is invalid. Can you share what push provider you are using? I'd check the response from APNs request to send if you have access to such information.A few things to check:1. Ensure background app refresh is enabled for the system, and subsequently, the application.2. Ensure low-data-mode is not configured for the connected network.3. Ensure low-power mode is not enabled (which disables background fetch)

Are you willing to share a sample body of your apns payload? When you submit your silent push to APNs, did you ensure that priority is set to 5 and your badge, sound, and alert keys are not specified?A few other things to check:1. Background app refresh2. Low data modeCheck out the "advances in networking part 2" from this summer, specifically the part about changes to "background fetch" when the new "low data mode" is enabled. Background fetch is described as something that WONT be executed if the user has low data mode enabled for their currently connected network.

Hey Steve,First of, I assume that you ommitted code from your didReceivePush code right? You'd normally want to do something in there with the userInfo that gets passed. I assume from "switch off and then switch on device", that you mean power off, and power back up? If so, are you expecting your app to still be running? 1. What service are you using to send your push notification?2. Is it an Alert notification or content-available one?3. Depending on 2, do you have the "priority" set correctly?4. Do you have the background mode checked for remote notifications?5. If content-available, did you ensure you didn't set alert body, sound, or badge?From some videos it sounds like they're starting to crack down on misconfigured pushes, but that is just speculation. I haven't seen any documentation to state pushes will STOP being sent if misconfigured.

For visible pushes, you'd have to build in something to prevent sending the push itself. It is by design that visible pushes are sent after the user killed the app. --> "Alert" notification.For silent pushes see below:This behavior is inconsistent with the documentation.https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623013-application?language=objc"However, the system does not automatically launch your app if the user has force-quit it. In that situation, the user must relaunch your app or restart the device before the system attempts to launch your app automatically again."To clarify, as the user, you swipe away your application from app switcher, and the OS is relaunching it silently to deliver "content-available = true" push notifications?Out of curiousity, what happens if you disable "background app refresh", or place your device in "low data mode". Both of these should also prevent "background fetch" from occurring. It would be interesting to see if this is not the case either with the latest OS version.I recently ran into the same thing for my app on iOS 13.2.x. As a developer, I'd like the ability to wake up the app given the appropriate circumstance. As a user, I would NOT want every single app to be able to do this without giving it express permission to do so. Enough tracking of users as it is. If I remove an app from app-switcher, I intend for it to not be allowed to run.