Callkit blocking behaviour is overridden in iOS 18

In iOS 18 if a number is registered with CallKit to be blocked, then if that number is also in contacts, then the number isn't blocked.

If a user has added a number to their contacts, then in all probability they might not want the number blocked, so this might seem reasonable behaviour. However the point is, this is new behaviour for CallKit in iOS 18, and its never been like this before going back several years to the very first release. Why suddenly change it now, after all these years, without notice nor documentation, and take away that option from the user, should for some reason, they want to block a number which is also in their contacts.

This is quite a disruptive change for apps using CallKit.

In iOS 18 if a number is registered with CallKit to be blocked, then if that number is also in contacts, then the number isn't blocked.

Have you filed a bug report on this and, if so, what's the bug number?

If a user has added a number to their contacts, then in all probability they might not want the number blocked, so this might seem reasonable behaviour. However the point is, this is new behaviour for CallKit in iOS 18, and its never been like this before going back several years to the very first release. Why suddenly change it now, after all these years, without notice nor documentation, and take away that option from the user, should for some reason, they want to block a number which is also in their contacts.

A few notes heres:

  • We added new call block APIs as part of iOS 18, so it's possible this was actually an accidental side effect of implementing the new call blocking APIs.

  • Users have multiple methods for blocking calls beyond the call directory extension. Manually adding the contact to the system level block list might work (I haven't tested this) but if it doesn't then "Focus" could also be used to block calls.

This is quite a disruptive change for apps using CallKit.

Why? All other issues aside, I'd expect this to be a fairly rare edge case. Is there a reason why this is particular issue for your users/use case?

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

It's a problem because people add known spammers to their contacts so as to identify them and not pick up the call.

So with this regression, all the known spammers that were added into users' contacts will be able to call users again.

Hi,

I'm experiencing this issue too and it has completely messed up the functioning of my app on iOS 18. Plus now that iOS 18 is live for the public, I'm getting complaints from my users, daily.

I've also filed a bug report for this (https://feedbackassistant.apple.com/feedback/15015052)

Please have the "Call Blocking & Identification" functionality back to how it was working on iOS 17.

Thanks

@Kevin Elliot "Why? All other issues aside, I'd expect this to be a fairly rare edge case. Is there a reason why this is particular issue for your users/use case?"

As echu says "It's a problem because people add known spammers to their contacts"

Exactly. I'm a developer, but also an iPhone user and as a user I do this myself.

Right! Me too. So now, iOS 18 is has a security loophole that lets spam calls through, that were previously blocked by apps that have implemented Call Blocking and Identification and was working well.

@DTS Engineer the answer cannot be for developers to ask thousands or millions of users to manually block spam callers they've added to their contacts. It's a terrible experience and customer support nightmare because of an Apple bug. Please fix this previously-working functionality that was broken in iOS 18.

It's a terrible experience and customer support nightmare because of an Apple bug. Please fix this previously-working functionality that was broken in iOS 18.

The single most important thing you can do here is file bugs. While it can seem like "talking to me here" is more useful/relevant, that isn't reality. Bug reports are the KEY tool for documenting issus, as they provide the written documentation that an issue is "real". I can (and have) tell the engineering team that an issue is important but that argument is much stronger when there are bugs documenting that reality.

Related to that point, one thing to understand here is that you're not filing bugs simply to tell us "look, I found a problem!". The bigger issue here is about work prioritization and fix management. Every change that's shipped as part of an update is evaluated for both "risk" ("How likely is this fix to break something else?") AND "benefit" ("How bad is the existing issue and who will this fix help?"). Developer bugs are absolutely CRITICAL on that second point.

If you need an issue fixed, then you need to file a bug asking for it to be fixed.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi Kevin,

We have reported this bug via the Feedback Assistant multiple times, the latest being report on 3rd Sep, 2024 here: https://feedbackassistant.apple.com/feedback/15015052

It still shows the status as: Recent Similar Reports:None Resolution:Open

  1. As this behavior is easily reproducible, and
  2. It does constitute a regression for many thousands of users who used call blocking and identification in a certain way

I believe this needs to be escalated internally and resolved to behave as it did previously OR explicitly state that this new behavior is what it is going to be in the future, so we can plan accordingly.

Thanks, T

We added new call block APIs as part of iOS 18, so it's possible this was actually an accidental side effect of implementing the new call blocking APIs.

Also regarding the whole topic, and as someone who tested the CXCallDirectoryProvider APIs before iOS 18, I can tell that a phone number registered in your contacts could not be blocked prior to iOS 18, it seems being known to the user was always overriding blocking. The issue might be somewhere else.

Callkit blocking behaviour is overridden in iOS 18
 
 
Q