Callkit call blocking problem

This behavior looks like a bug and is unexpected when using our application.

I could argue either side of this issue. There's a "hierarchy" in place that prioritizes different identification/blocking data sources, with the users own contact configuration being considered the most "authoritative". I believe the contact entry would always have overriden an external blocking entry, so the change here is really about giving the outgoing recents call higher "authority".

Was this a planned callkit change in iOS 26?

Yes and no. I'm not sure there was a formal decision that this was a particular case we should handle differently, however, adding support for LiveCaller ID involved large scale changes throughout this area. Part of that process involved reviewing all of our data sources and that review is what changed the behavior here.

Is it possible to get the correct call blocking behavior back?

I don't know. Please file a bug on this and post the number back here.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks for the reply

We filed bug report with Feedback Assistant: FB20266760

We agree that user contacts have the highest priority. But as for the outgoing recents calls, it is important for us that our application can block them.

We will wait for the decision on this issue. If anything else is needed to investigate this issue, please let me know

I'm encountering the same issue, got any response to your bug report?

We agree that user contacts have the highest priority. But as for the outgoing recent calls, it is important for us that our application can block them.

One thing that I'd like to understand here is what the actual use case/concern is here.

The reverse (why wouldn't block these calls) is straightforward to explain— as call blocking, particularly more “real-time" block-like Live CallerID, becomes more widespread, it's going to be more and more likely that numbers will be incorrectly blocked, even if it's only temporary. Checking outgoing calls on the recent list is an easy way to mitigate that, as it means numbers won't stay blocked and reduces the disruption to ongoing communication.

What's the situation where your app is adding calls to its blocking list which the user has actively called?

We will wait for the decision on this issue. If anything else is needed to investigate this issue, please let me know.

If you've got a specific use case that answers my question above, then that's something I'd love to see added to your bug.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

One of the features of our app is the ability to create your own list of blocked calls (spam or unwanted).

For example, a user missed a call from an unknown number. He called back and decided it was spam and added this number to his list of blocked calls in our app. But since there's an outgoing call to this number in the Phone.app Recents, it won't be blocked. Removing the outgoing call record from the Phone.app Recents is a rather non-obvious action in this situation.

As result, the user blocked the number through our app, but continue received calls from it

What's the situation where your app is adding calls to its blocking list which the user has actively called?

Blocking will not work if at least one outgoing call has been made to the blocked number. One call back is not an actively called number.

But even if a user was actively called with another person, and then decided to interrupt the communication and block him, why should the presence in the Phone.app Recents prevent this?

It looks like that the blocking function advertised in the app does not work. I will also add this example to my bug report

In my case, when my user receives an incoming call from an unknown number, she can only realize it is a scam after answering the call. After that, she decides to block the number in my app. However, the blocking feature does not seem to work on OS 26.

Normally, a user would receive a call from an unknown number, recognize it as a scam, and then use the block feature. In this scenario, after the call ends, the block should take effect properly on OS 26.

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

In my case, when my user receives an incoming call from an unknown number, she can only realize it is a scam after answering the call. After that, she decides to block the number in my app. However, the blocking feature does not seem to work on OS 26.

I believe this particular case should work the same on iOS 26. The different behavior here is if she called that number, THEN blocked the number through your app.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware