Ok, so found that that if you don't have the background capability of push notifications to your project then you have to call requestAuthorization() in order to get the push token, as described above. But when you add that background capability, then you can obtain the token without calling requestAuthorization(). What's with that?

@Argun Tekant Thank you. In my case the NSE has the filtering entitlement, how does that change the list of pre-conditions?

@Argun Tekant Thank you, however having to obtain notification authorization for background silent notifications seems to be contradictory to this logic? The app can consume and do something with the push without it resulting in a notification.

@Kevin Elliot "One thing that I'd like to understand here is what the actual use case/concern is here." What if, as a user, you receive a call from an unknown caller. You don't answer, but instead call that number back to see whom, if anybody, answers. If after doing that you decide the caller is a spammer, or nuisance caller, whatever, and you decide to use an app using CallKit to block the number. Well, that caller is not going to be blocked due to the outgoing call.

I know what the local laws are and how they apply to users. Texas requires this, but the USA has 50 states. If an app is destined for distribution in the USA, in order to comply with Texas, its necessary to force users of the other 49 states to go through this even though they don't live in Texas? Have Apple considered this and provide a solution to this situation? Making all users of the app perform something intrusive and unnecessary just because Texas says its necessary.

I was asking the same question on here several months ago, seems there is no way. Do you have an Apple IP range list? How did you obtain it, how do you know it won't change at some point in the future though.

@eskimo Hello "Or because you’re trying to decide how to handle the error?" Yes. In the example you gave that's a compile-time programming error. I'd like to know if there are any errors that can occur at run time for example and are re-tryable, for example any errors caused by connectivity failures, in which case if the app tried again then next time the failure might succeed?

I first encountered this issue many years ago, and yes, like you say, once it has occurred its not possible to recover, the user has no option but to hard reset their phone if they want to be able to use the app. I tried to find my post(s) about it but the forum only seems to archive posts from 2021 onwards.

"(its more complex to verify as app A is developed by one company and app B by another)" Just to clarify, developed by different companies, but having the same bundle id stems (possible as provisioning profiles, signing certificate etc. have been shared from on company to the other)

"we don't "mix" data like this. There's basically a "hierarchy" of data sources and we only present the data from that data source (whichever one "works"). For example, if there is a contact card for a specific number then that's what we're going to show to that user, regardless of what any other data source would have returned*." @Kevin Elliott When there is an incomming call what is the hierarchy of data sources? I would guess from my observations its: Contacts Call Directory Extension Live Caller ID SIP header content Would that be correct? There's additionally Voip Calls, but beyond that, are there other sources of data where call time information is extracted from to display on the call screen? Thank you

I've been using NSEs extensively for a decade. I've noticed very occasionally something in the OS just seems to get broken. Have you tried simply rebooting the phone? That's fixed inexplicable out-of-nowhere issues for me in the past.