You could implement a notification service extension to receive the push notifications, and request from Apple that they grant your app the com.apple.developer.usernotifications.filtering entitlement. Set up a shared group between the app and the extension (i.e. to house shared defaults). When the user toggles on/off the switch the app writes that to the group defaults. When the extension receives a push, the extension reads the toggle switch setting from shared defaults and if the user has turned them off then the entitlement will enable the extension to suppress the displaying of the notification.

@SurbhiArora did you find a solution to this problem?

@EdifyDeveloper I have the same problem, did you find a solution?

It's the opposite to what you are assuming. If you register a number with CallKit then make a regular call to the handset, then the number will be either blocked or display additional information on the call screen (depending upon if you used CallKit to block or identify the number). However if you make a VoiP call then it is neither blocked nor identified.

When an app gets rejected you have the ability to respond directly to the review team, why have you not done that and instead posted here. Posting here isn't going to achieve anything. Communicate with the review team and explain exactly why your app needs the address.

Found some more info here https://developer.apple.com/documentation/callkit/sending_end-to-end_encrypted_voip_calls So its not intended for the extension to receive a voip push, its for the extension to receive a regular push.

@eskimo "VoIP transport is all about how your app actually transfers voice data on the wire. iOS does not have specific APIs for this" Hello, you wrote this 6 years ago, is that still the situation today?

@langaCom "While you must report an incoming call immediately, you are still free to decide the call has failed and tell the system later, asynchronously. To do this, call reportCallWithUUID:endedAtDate:reason:. This will tear down the incoming call UI even if the user has not answered the call." But the call screen UI will still be displayed, even if just momentarily. This makes it look scrappy, messy, broken, unprofessional.

You can't

I found out what the problem is - which I believe must be a bug in Xcode in how it creates the extension target. If different types of extension are created (for example an action extension or a call extension) then if you look at the Code Signing Entitlements section within Build Settings its empty. However, if a background asset download extension is created then it's not empty. If its changed to be empty then the problems described above go away.

App-directed pushes are not delivered to your app if your app is terminated or in the background (unless just moved to the background) so using an app-directed push just isn't going to be able to do what you want. So you'll have to investigate if a notification service extension has the ability to do what you want.

You can send it using HTTP, exactly how the HTTP content is structured is up to you. Once you've sent it, your app needs to check to see if its changes (its not often, but it can), if so then you have to send the new one.

"What other reasons could there be that a push message was sent but did not reach the application?" PushSharp is sending the pushes over the Apple production environment but the app you're trying send them to is a debug build, or vice versa. Your target handset has got Personal Focus currently turned on You are sending app-directed pushes but the app is terminated

Did you find the reason why you're widget isn't updating?

The asset download extension would have been an opportunity to transmit the new push token, but the documentation for it says "Use the framework only to download additional assets for your app; don’t use it for any other purposes. For example, don’t collect or transmit data"