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.

You can't

@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.

@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?

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.

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.

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.

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

@SurbhiArora did you find a solution to this problem?

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.

It's not possible for your application to know when there is an incoming call, nor get any information whatsoever when there is a call such as the calling number, let along have access to the audio. So your idea for call recording is dead in the water (unless you are implementing a VoIP call app, but if you are you don't say so)

Hey, com.apple.developer.pushkit.unrestricted-voip no longer works today - it stops working if you build your app with Xcode 13 onwards. So as its already no longer supported I'm confused by your question.

It can't be achieved. You can't make notification trigger based on arbitrary events, nor can you make your app launch in order to post the notification.

Asynchronous is asynchronous. You have to learn how to design and implement your code to take account of that.

Errm, wouldn't it be better to instead eliminate the crash from your extension??? Common reasons for getting a crash with the call extension are: a) you're loading up too many/large data structures at once and are running out of memory, i.e. you load up an array of phone numbers which is hundreds of thousands entries b) you attempt to add a duplicate phone number c) the phone numbers are not sorted in order.