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)

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.

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

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.

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

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.

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)

Thanks for the update, we hope that this will be resolved.

Thank you for sharing your test results. However, I'm observing a different behavior on iOS 18.2 (22C152): When a call is blocked via CallKit, it appears as "unanswered" in the call history The notification badge appears in the Phone app when testing in iOS 18.2 There's no indication of which app blocked the call in the Recents Tab log My testing scenario: Fresh install of a CallKit app with call blocking functionality Set up app rules to block a specific number Call from that number (not blocked at OS level or anywhere else) to my iPhone Call comes through as "unanswered" in history

Bumping this post, as the bug is still not fixed in iOS 18.2 as promised. Blocked calls still appear as "unanswered" in the Recents Tab in the Phone app. This behavior change is having a significant negative impact on our business: We're receiving numerous negative App Store reviews Users are uninstalling our app thinking it's not working Our support team is overwhelmed with complaints about this issue This system-level change has severely impacted user trust in call blocking apps and is causing real business damage to developers. Any timeline on when this counterintuitive behavior will be addressed? Our users and business continue to suffer from this change.

Thank you for your response. However, I have some important points to raise: Could you please point to the forum posts where developers confirmed this was resolved? I've tested several other call blocking apps on iOS 18.2, and they all exhibit the same behavior - blocked calls appearing as "unanswered". This suggests the issue is not resolved. Most critically, this iOS 18 behavior change is having a significant negative impact on our business: We're receiving numerous negative App Store reviews Users are uninstalling our app thinking it's not working Our support team is overwhelmed with complaints about this issue This system-level change has severely impacted user trust in call blocking apps and is causing real business damage to developers.

@DTS Engineer Following up, have you had a chance to review the feedback report (FB16093992)? The behavior with blocked calls appearing as "unanswered" is still present in iOS 18.2. Any insights would be appreciated.

@DTS Engineer Following up, have you had a chance to review the feedback report (FB16093992)? The behavior with blocked calls appearing as "unanswered" is still present in iOS 18.2. Any insights would be appreciated.

We have filed a bug report with bug number: FB16093992