[tags:wwdc20-10138]

Hi, We've noticed that this issue occurs more frequently after upgrading to iOS 18.4.1 and can result in one-way audio. Our app uses CallKit with WebRTC to establish VoIP connections. However, on iOS 18.4.1, CallKit no longer triggers: func provider(_ provider: CXProvider, didActivate audioSession: AVAudioSession) We're currently comparing the occurrence rate across different iOS versions to better understand the impact. Could you please help analyze the root cause of this issue?

We are not receving incoming call from blocked numbers below iOS 26 versions but same in iOS 26 onwards we are receiving the incoming call.. Can you please provide any solutions to fix the issue

We tested call blocking on iOS 26 and noticed something strange: the call will not be blocked if an outgoing call was made to its number before. Nevertheless, it will be blocked if we delete the outgoing call record from the Phone.app Recents. This behavior looks like a bug and is unexpected when using our application. Was this a planned callkit change in iOS 26? Is it possible to get the correct call blocking behavior back? We set blocking rules with addBlockingEntry(withNextSequentialPhoneNumber:) and this problem is not present in iOS 18 and earlier. Thank you in advance

Certainly! Here's a concise version of your forum post: Title: Issues Handling Multiple Incoming Calls in CallKit Body: Hello, I'm using CallKit and I am encountering challenges with handling multiple incoming calls. Current Configuration: configuration.maximumCallsPerCallGroup = 5 configuration.maximumCallGroups = 3 This setup aims to allow up to 5 calls per group. Observed Behavior: Despite the configuration, the system UI seems to limit the number of calls per group, often defaulting to End & Accept instead of Hold & Accept when a third call comes in. Questions: Is there a documented system-imposed limit on the number of calls per group or total calls, even if maximumCallGroups and maximumCallsPerCallGroup are set higher? How does the system UI behave when these limits are exceeded? Are there known UI constraints or fallback behaviors? Are there best practices for handling scenarios where the system UI cannot display all calls, such as gracefully managing incoming calls or providing alternative UI

We require assistance in resolving a critical audio design conflict within our Push-to-Talk (PTT) application. Our current volume amplification strategy—which relies on applying a GAIN factor to PCM samples in conjunction with setting the AVAudioSession category to Playback—is working successfully when PTT is used independently. However, upon integrating and reporting the same PTT call through the CallKit framework, this amplification effect is lost. The CallKit integration appears to be forcing a different, non-amplifying audio session category or configuration, negatively impacting the user's perceived call volume. We need guidance on how to maintain the AVAudioSessionCategoryPlayback setting, or an equivalent high-volume configuration, while operating under the control of CallKit.

Hello, In production, a large number of users experience outgoing call reporting fails with the following error: com.apple.CallKit.error.requesttransaction Code=2 The iOS version doesn't matter, errors are present in v15-26 Details My CXProvider held as a global singleton, so it’s unlikely to be deinited. There is no explicit call to CXProvider.invalidate() in the app. If I manually invalidate the CXProvider, I observe the expected failure when trying to create an outgoing call (com.apple.CallKit.error.requesttransaction error 2). However, If I recreate the CXProvider after the error, outgoing calls are reported correctly. Many users trigger the providerDidReset delegate method (CXProviderDelegate) before this error. According to the documentation, providerDidReset can be called by the system, and we are supposed to end all active calls, but the documentation doesn't suggest recreating the CXProvider. Question Should I recreate CXProvider after providerDidReset and forget about that, or could this error be ca

[Question] Inconsistent Call Directory number matching across regions (Japan, Taiwan, U.S.) We’re developing a Call Directory extension and observed inconsistent number matching depending on carrier region and number format. Environment Device: iPhone (iOS 26.0) Call Directory Extension: Custom implementation Carrier A: Japan carrier SIM Carrier B: Taiwan carrier SIM Numbers added to Call Directory patterns: +81 120 580 2XXX +81 704 336 2XXX Observed Behavior (Japan Carrier SIM) Incoming call from +81 120 580 2XXX → Caller name not displayed (Call Directory match failed). Entering 0120 580 2XXX in the Phone app dialer → Name displayed correctly. Incoming call from +81 704 336 2XXX → Caller name displayed correctly. Entering 070 4336 2XXX in the Phone app dialer → Name displayed correctly. Observed Behavior (Taiwan Carrier SIM) Entering +81 120 580 2XXX in the dialer → Name not displayed until the call button is pressed. Entering +81 704 336 2XXX in the dialer → Name displayed immediately, before the call is p

I'm building a React Native call application using the following combination of libraries: https://github.com/react-native-webrtc/react-native-callkeep https://github.com/react-native-webrtc/react-native-webrtc https://github.com/react-native-webrtc/react-native-voip-push-notification When I press the speaker button on the call screen displayed by CallKit and change it to ON, the speaker button display on the call screen reverts back to OFF after a few seconds. However, when the speaker button display reverts to OFF, the actual audio output route does not return to the earpiece - the audio continues to output from the speaker without any change. Could you please advise on what cases might cause the speaker button display to revert, and if there are any potential solutions?

Hello fellow developers, Anyone blocked at the Live Caller ID Lookup configuration step? I submitted multiple times the form without any news from Apple since a few months (last one is FL7S57UFVR). This is blocking our app release to our customers. Thank you

Hi, Since I updated my phone to 23A341, my Call filtering app is not blocking calls anymore. Same release checked on iOS 18 phone, it is working. I still see the callkit logs into the Console showing that numbers are loaded into the iOS-managed SQlite DB but the calls are not blocked nor identified. Anyone with the same issue? BR

Is the API of Live Caller ID Lookup not open to ordinary developers? How can I get the development permission of Live Caller ID Lookup?

Currenty, I'm developing a blocking and call identity call. In iOS 18, everything works fine, I can show log to debug inside my Callkit extensions But when my app run in iOS 26, I cant even turn on my caller id extension, I'm not able to debug because I dont see any log from my extensions.

Our VoIP app receives PushKit notifications successfully (callservicesd Delivering 1 VoIP payload appears in logs). However, the app is consistently terminated by the system when running in the background or killed state. The crash is caused by iOS expecting a reportNewIncomingCall to CallKit, but the system reports: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Killing app because it never posted an incoming call to the system after receiving a PushKit VoIP push.' *** Assertion failure in -[PKPushRegistry _terminateAppIfThereAreUnhandledVoIPPushes], PKPushRegistry.m:349 Key Observations: VoIP pushes arrive and are delivered to the app. In foreground, some methods work and CallKit UI sometimes appears. In background/killed state, app is always terminated before CallKit UI shows. Logs confirm the system requires CallKit to be reported immediately inside pushRegistry(_:didReceiveIncomingPushWith:for:completion:). Steps to Reproduce: Run the app with VoIP + CallKit in

I have also tested this on iOS 26 (Beta 9 and above), and the CallKit call blocking functionality is not working. Numbers that should be blocked still ring through. Caller Identification continues to function as expected, but blocking entries (addBlockingEntry) are ignored.

I’m developing a VoIP app that uses Linphone and CallKit. Everything works as expected until the user enables the speaker on the native CallKit screen. After that, all subsequent calls start with the speaker already on. Even if I call AVAudioSession.sharedInstance().overrideOutputAudioPort(.none), it gets overridden when the call starts (when Linphone begins playing the ringtone). I tested this behavior in WhatsApp, and it seems to work correctly there.