Call Blocking (CallKit) not working on iOS 26 Public Beta

We got several user complaints about our app that is not working on iOS 26 Public Beta.

...

We've filed 2 bug reports with Feedback Assistant: FB19140680 FB19140594

What API are you blocking calls with? Have you looked into what's actually failing (crashing/hanging/etc)? There's a crash in callservicesd that might cause what you're describing, however, neither of your bugs has enough diagnostic to confirm that's the case or whether it's a different issues.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks for the reply.

We're using CXCallDirectoryProvider and we've made no changes in our end. The strange part is that all the call blocking apps I've tried didn't blocked any calls based on my given rules (but when testing with iOS 18.x they did). After checking the logs, I didn't found anything suspicious.

Did you made any changes to CXCallDirectoryProvider or CallKit that may prevent call blocking? (or maybe with the new changes that introduced with call filtering etc in iOS 26)

In addition, when using the addIdentificationEntryWithNextSequentialPhoneNumber to identify calls, identification works great. But not when using addBlockingEntryWithNextSequentialPhoneNumber.

I've tried lots of call blocking apps (6 apps) and none of them was able to block a call anymore, so this indicates that this should be an issue in iOS side.

Did you make any changes to CXCallDirectoryProvider or CallKit that may prevent call blocking?

No, nothing specific to CXCallDirectory changed. However...

(or maybe with the new changes that were introduced with call filtering etc in iOS 26)

...there were lots of changes in this area as part of the introduction of Live Caller ID.

I've tried lots of call blocking apps (6 apps) and none of them was able to block a call anymore, so this indicates that this should be an issue on the iOS side.

Yes, that sounds reasonably likely. However, I need to jump back and expand on what I said here:

There's a crash in callservicesd that might cause what you're describing; however, neither of your bugs has enough diagnostic information to confirm that's the case or whether it's a different issue.

Broadly speaking, most developer bugs I look at fall along this spectrum, depending on the level of detail they contain:

1. User bug -> This doesn't work.

2. Developer "User" bug -> This API/part of my app doesn't work.

3. Minimal Testing -> This doesn't work and I've collected a sysdiagnose of the problem.

4. Actionable Bug -> This doesn't work and here is all the data I've collected trying to investigate the issue along with a test app that replicates the problem.

The practical reality here is that the closer you get to #4, the more likely it is your bug will be addressed. Like any engineering organization, we have to make decisions about what bugs to prioritize and part of that process is simply how much work it will take to investigate the issue, so anything you can do to "speed up" the investigation makes it more likely that your bug will be addressed.

However, the other key point is here:

...confirm that's the case or whether it's a different issue.

As you've noted, multiple other apps are experiencing the same user-level problem ("This doesn't work"). That doesn't mean they're actually failing in the same way, and unless you provide the engineering team with the necessary information, there's no way for them to know either. If you want to make sure your app works, then you need to give the team the information required to actually investigate your app’s failure.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I have updated the FB19140680 incident with the following:

• Full sysdiagnose log of iOS before I receive the call from the number that failed to be blocked
• Logs (via the Console app) when I added the blocking rules with my app using CallKit
• Logs (via the Console app) when I receive the call from the number that failed to be blocked

In addition, I closed FB19140594 incident as it was a duplicate

I hope this helps expedite the process and narrow down the issue.

I have updated the FB19140680 incident with the following:

So, I just looked at the sysdiagnose and I'm afraid it won't be all that useful. The call in question happened around 14:33, but the device was rebooted multiple time after that point. Unfortunately, significant log data is discarded when the device reboots and that lost data makes it impossible to really investigate this kind of issue, as there are simply to many "holes" in the console log data.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks for checking the sysdiagnose and sorry for the "bad" log.

I've collected a fresh new sysdiagnose right before the call (the call passed through at 07:09) and I've uploaded it to the FB bug.

Additionally, if there are any other specific logs, diagnostic data, or testing scenarios that would be helpful for investigating this issue, please let me know. I'm happy to provide whatever additional information would be most useful for the engineering team.

I've collected a fresh new sysdiagnose right before the call (the call passed through at 07:09) and I've uploaded it to the FB bug.

I spent some time looking at that log and couldn't find any clear issue, but it does look like the right data. One question though— are you adding a blocking AND an identification entry for the same number?

2025-07-31 07:09:56.997400+0300 communicationtrustd:  Looking up call directory blocked entries for handles <private>
2025-07-31 07:09:56.998039+0300 communicationtrustd:  Call directory blocked entries found <private>
2025-07-31 07:09:56.998065+0300 communicationtrustd:  Looking up call directory identification entries for handles <private>
2025-07-31 07:09:56.998069+0300 communicationtrustd:  Call directory identification entries found <private>

My concern here is that there have always been issues around how Phone.app should handle "conflicting" information coming from different sources. As a more concrete example of this, I have a full write-up here on how/why the users’ local contact database will automatically override CXCallDirectory data.

In any case, I'm not sure what our previous behavior was, but I can easily see the work we did in this area changing the behavior of an edge case like what should happen when a blocking and ID entry exist for the same number.

As a side note on this, I think the correct behavior here would be to report the call to the user (instead of blocking). One source is saying the number is "valid" (by providing an ID) while the other "invalid" (by setting a block), but it's much easier for the user to block a number than it is for them to figure out how to make a number work that won't ring.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

are you adding a blocking AND an identification entry for the same number?

No, I either block or identify a call in my app, but never both at the same time.

Regarding the potential conflict between blocking and identification entries - if this is indeed the root cause, it seems like this conflict behavior must have changed in iOS 26 Beta.

I want to note that almost daily I'm getting user reports from iOS 26 beta users reporting that my app suddenly stopped blocking calls (but it was functioning normally on iOS 18.x).

In addition, I had tested similar call blocking apps and their block function was working on iOS 18.x, but stopped working in iOS 26 Beta.

Based on the evidence we've gathered - multiple apps failing, user reports, and the systematic nature of this issue - I'd like to request that this be escalated to the appropriate engineering team for investigation. This seems to be a significant regression that could impact the entire call blocking ecosystem when iOS 26 releases.

Based on the evidence we've gathered - multiple apps failing, user reports, and the systematic nature of this issue - I'd like to request that this be escalated to the appropriate engineering team for investigation.

That's already been happening. With any bug I'm involved with, I make sure the bug is routed properly at the same time I do my own investigation, then update the bug with anything I've found so I can help move the bug along.

No, I either block or identify a call in my app, but never both at the same time.

Good, thank you for clarifying.

Regarding the potential conflict between blocking and identification entries - if this is indeed the root cause,

Again, to be clear, I don't know that this is what's going on here, I just wanted to rule out something odd I'd noticed in the log data.

Similarly, on this point:

it seems like this conflict behavior must have changed in iOS 26 Beta.

Yes, that is what I was saying. More specifically, we've added more sources of identification data and we haven't (and probably won't) defined exactly how we'll sort out those conflicts. Stating this more clearly:

1. The basic case of blocking a single number that nothing else in the system "knows" about should just work. If it doesn't, then that's a bug.

2. Complicated cases where data is coming from multiple sources are inherently ambiguous, requiring a much more detailed look at the exact configuration of data sources.

In the case here, I want to be sure that we're NOT dealing with #2 and, if we are, then I want to get a much better understanding of exactly what that configuration is.

Coming at this from the other direction, have you tested this test device that's been reset, doesn't have anything else installed, and has never been called by that number before (well, since the device was reset)?

My concern here is actually around this point:

This seems to be a significant regression that could impact the entire call blocking ecosystem when iOS 26 releases.

That's exactly what I'm concerned about. As far as I can tell, this is the only report we've received on this, and I'd expect us to have far more than that. Is there any other factor we might be missing here? Have you tested with multiple phone numbers (since that would explain why it fails in other apps)?

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

FWIW I've got an app in the App Store using CallKit to block and identify calls. After reading this thread I gave it try out with some iOS 16 devices but didn't encounter any issues. Doesn't mean there aren't any of course, but at least its not something endemic affecting all apps/users.

I'll keep watching the thread with interest.

That's already been happening.

Thanks for clarifying that.

Coming at this from the other direction, have you tested this test device that's been reset, doesn't have anything else installed, and has never been called by that number before (well, since the device was reset)?

No, I haven't tested on a factory reset device.

Have you tested with multiple phone numbers (since that would explain why it fails in other apps)?

Yes, I did multiple tests with different phone numbers.

Is there any other factor we might be missing here?

I guess this should be a higher-level logging but I constantly see a "blocked=0" in the custom logs I've attached in FB (call_received.txt). I got those using the Console app monitoring my device and filtering for 'CallKit' when the call received.

Example (I've replaced the real number with '1234567' here for privacy reasons):

default	14:33:11.270045+0300	callservicesd	Checking live blocking info using handle: 1234567
default	14:33:11.270051+0300	callservicesd	fetchLiveBlockingInfoForHandle handle=1234567
default	14:33:11.270057+0300	callservicesd	fetchLiveBlockingInfoForHandle: 1234567
default	14:33:11.270127+0300	callservicesd	fetchLiveBlockingInfoForHandle blocked=0
default	14:33:11.270132+0300	callservicesd	fetchLiveBlockingInfoForHandle handle=1234567 block=NO

No, I haven't tested on a factory reset device.

...

Yes, I did multiple tests with different phone numbers.

I'd recommend doing so, but if you can’t, then make sure you're testing with a number that the device does not "know" about in any way (particularly the call list). This is entirely a guess, but we just did a lot of work on how the recent call list is handled and displayed, and one possibility here is that a mistake in that process could end up treating an older call (which we blocked) as a "known" caller. That's an edge case I'd like to rule out.

Also, on the logging front, you may want to install either the "Facetime" or "Phone (General)" debugging profiles*, which will provide more details in the log data.

*Those are actually the exact same profiles with different download links, but I'm including both for completeness.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Yes, I have tested a number that I never received a call from before, blocking didn't work.

I have uploaded a new sysdiagnose ZIP (after installing the debugging profile) in the FB bug.

Coming at this from the other direction, have you tested this test device that's been reset, doesn't have anything else installed, and has never been called by that number before (well, since the device was reset)?

I have also tested with a factory reset device (using the debugging profile) and still the call blocking didn't worked. I have attached a sysdiagnose ZIP as well in the FB bug (sysdiagnose_2025.08.05_10-45-11+0300_iPhone-OS_iPhone_23A5297m.tar.gz)