Starting in iOS 26, two notable changes have been made to CallKit, LiveCommunicationKit, and the PushToTalk framework:
As a diagnostic aid, we're introducing new dialogs to warn apps of voip push related issue, for example when they fail to report a call or when when voip push delivery stops. The specific details of that behavior are still being determined and are likely to change over time, however, the critical point here is that these alerts are only intended to help developers debug and improve their app. Because of that, they're specifically tied to development and TestFlight signed builds, so the alert dialogs will not appear for customers running app store builds. The existing termination/crashes will still occur, but the new warning alerts will not appear.
As PushToTalk developers have previously been warned, the last unrestricted PushKit entitlement ("com.apple.developer.pushkit.unrestricted-voip.ptt") has been disabled in the iOS 26 SDK. ALL apps that link against the iOS 26 SDK which receive a voip push through PushKit and which fail to report a call to CallKit will be now be terminated by the system, as the API contract has long specified.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
CallKit
RSS for tagDisplay the system-calling UI for your app’s VoIP services and coordinate your calling services with other apps and the system using CallKit.
Posts under CallKit tag
157 Posts
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Hi everyone,
I’ve filed a Feedback report (FB20986470) for a serious issue affecting the Call Directory database when add phone numbers for call blocking.
When adding blocking numbers to a Call Directory extension, the system’s CallKit database (/private/var/mobile/Library/CallDirectory/CallDirectory.db) becomes corrupted.
The reload call (reloadExtensionWithIdentifier) fails with error code 11 when the system tries to insert blocking entries, and the Console app on macOS shows the following errors:
database corruption page 2265525 of /private/var/mobile/Library/CallDirectory/CallDirectory.db at line 81343 of [f0ca7bba1c]
database corruption at line 79387 of [f0ca7bba1c]
Error Domain=com.apple.callkit.database.sqlite Code=11 "sqlite3_step for query 'INSERT INTO PhoneNumberBlockingEntry (extension_id, phone_number_id) VALUES (?, (SELECT id FROM PhoneNumber WHERE (number = ?))), (?, (SELECT id FROM PhoneNumber WHERE (number = ?))),...)'"
After this happens, CallKit becomes fully corrupted on the device and no further numbers can be added, even after:
Disabling and re-enabling the extension
Restarting the device (either force or soft restart)
Reinstalling the app
Waiting for a couple of minutes after this issue happens (that CallKit could possibly self-recovered)
I also tested other call-blocking apps, and they all fail with the same error. The only thing that recovers the system is a full “Reset All Settings.”
This issue has been reported by many users of my app, across multiple iOS versions and devices.
Similar related issue reported by another developer:
https://developer.apple.com/forums/thread/806129
Steps to Reproduce:
Enable the Call Directory extension from a call-blocking app.
Add and reload blocking numbers (a few thousand entries).
Perform multiple reloads between additions.
Check the Console, the corruption errors appear.
From this point, all insert attempts fail system-wide.
Expected Result:
Entries should be inserted successfully, or the system should self-recover without persistent corruption.
Actual Result:
sqlite3_step fails with Code=11, and the Call Directory database remains corrupted until the user resets all settings.
Additional Notes:
All numbers are sorted and deduplicated before insertion.
Happens intermittently after multiple reloads.
The system log always shows internal database failure.
Environment:
Device: iPhone 16 Plus
iOS 18.2 Beta (23C5027f)
Xcode 16.1 (17B55)
Attachments (included in Feedback FB20986470):
sysdiagnose captured immediately after the failure (with Phone app General Profile)
It seems like a system-level corruption affecting all Call Directory extensions once it occurs.
Since I updated to iOS 18, CallKit-linked caller not display on screen of CarPlay.
CarPlay display only "{App Name} Caller ID".
When iOS version was 17.x, CarPlay displayed caller name of CallKit-linked contact.
I think CarPlay should perform the same function as iOS 17.
Please review it.
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 solutions?
Any insights or experiences with similar configurations would be greatly appreciated.
Thank you.
Feel free to copy and paste this directly into the Apple Developer Forums. If you need further assistance or adjustments, let me know!
I have an app developed by using the Callkit/Call-Blocking and received feedback from individual users, when using [cxcalldirectorymanager reloadextensionwithidentifier] to write call blocking data, it returned error code 11 with the following contents:
errorCode: 11
errorDomain: com.apple.callkit.database.sqlite
errorDescription: sqlite3_step for query 'DELETE FROM PhoneNumberBlockingEntry WHERE extension_id =?' returned 11 (11) errorMessage 'database disk image is malformed'
I want to know the reasons for this error and how to solve it,Thanks!
I have an app developed by using the Callkit/Call-Blocking and received feedback from individual users, when using [cxcalldirectorymanager reloadextensionwithidentifier] to write call blocking data, it returned error code 11 with the following contents:
errorCode: 11
errorDomain: com.apple.callkit.database.sqlite
errorDescription: sqlite3_step for query 'DELETE FROM PhoneNumberBlockingEntry WHERE extension_id =?' returned 11 (11) errorMessage 'database disk image is malformed'
I want to know the reasons for this error and how to solve it,Thanks!
My app uses CallKit and PushKit for real-time voice and video calls.
I want to configure VoIP push notifications so incoming calls can wake the app,
even when it’s in the background or terminated.
Right now, I only see the normal Push Notifications option in my App ID settings
and no VoIP Services section.
Hello,
We are facing issue that sometimes a voip notification gets delivered after it is expired. The issue can be simply demonstrated we set the device to flight mode, and after 20s we disable flight mode. We still receive the voip notification.
We are setting the expiration header as following apns-expiry=0, so from my understanding it should not be delivered if the device was not able to receive the notification in the fist attempt.
I have read following thread https://developer.apple.com/forums/thread/778512, from which I understand this is a long standing issue.
Hence my question is, is there any way how we can notify the call kit that the call is actually no longer valid, and do not display the call to the user at all?
Currently we are forced to always display CallKit call when the notification comes, and some of our users are confused that they see a missed call which they did not have any chance to pick up.
Please let me know if you need any more information.
Best Regards,
Adam Chlupacek
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.
On iOS 26, calling CXCallDirectoryManager.sharedInstance.openSettings() does not navigate to the “Call Blocking & Identification” settings page as documented. Instead, it either opens the main Phone settings page or fails to navigate entirely. This breaks the expected behavior for enabling Call Directory extensions and impacts onboarding flows for apps using CallKit.
Expected:
Settings should open directly to Phone → Call Blocking & Identification.
Actual:
Navigates to the main Phone settings page
This appears to be a regression from previous iOS versions. Documentation still states this API should open the correct page.
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
Subject: Call Directory Extension Enable Failure for Individual User
Dear Apple Developer Support,
We are experiencing an issue with our Call Directory Extension where one specific user cannot enable it, while thousands of other users on the same iOS version can enable it successfully.
Issue Details:
App: 美信 (Midea Connect)
Problem: Extension fails to enable with error: "请求'美信'的数据时失败" (Failed to request data from app)
Affected: 1 user out of thousands
iOS Version: 26.0.1
What Works:
All other users can enable the extension normally
Same iOS version, no issues
App Group and Extension identifier are correctly configured
User Has Tried:
Reinstall app - No effect
Toggle extension off/on - Still fails
Restart device - No improvement
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 caused by something else?
Application is in foreground state, When a user receives a cellular call and it is in the "ringing" state and application receives a VoIP APNS(video call) which is reported to CallKit.
User rejects the Cellular call from CallKit UI, application Video call is also getting rejected (separate feedback - 19017978) and Here the issue is observed that an Application moved to background.
Issue is not observed in iOS 18 and older versions.
Issue observed only with UISceneDelegate changes. Using traditional UIApplicationDelegate doesn't have the issues.
Video and Sysdiagnose logs are added in feedback: FB20187309
[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 placed.
Steps to Reproduce
For Japan carrier:
Use a device running iOS 26 with a Japanese SIM card.
Add the following numbers to the Call Directory extension:
+81 120 580 2XXX and +81 704 336 2XXX
Receive an incoming call from +81 120 580 2XXX → ❌ Caller name not displayed.
Open the Phone app and enter 0120 580 2XXX → ✅ Caller name displayed.
Receive an incoming call from +81 704 336 2XXX → ✅ Caller name displayed.
Open the Phone app and enter 070 4336 2XXX → ✅ Caller name displayed.
For Taiwan carrier:
7. Insert a Taiwan SIM card (keep the same Call Directory patterns).
8. Enter +81 120 580 2XXX → ❌ Name not shown until the call button is pressed.
9. Enter +81 704 336 2XXX → ✅ Name shown immediately.
Expected Result
For both numbers:
Caller name from Call Directory should display consistently:
a) On incoming calls.
b) When entering the full number in the dialer (before pressing call).
Behavior should be consistent across regions (Japan, Taiwan, United States).
Actual Result
Region / Carrier
Number Pattern
Incoming Call
Dialer (Local Format)
Japan
+81 120 580 2XXX
❌ Not shown
✅ Shown (0120 580 2XXX)
Japan
+81 704 336 2XXX
✅ Shown
✅ Shown (070 4336 2XXX)
Taiwan
+81 120 580 2XXX
N/A
❌ Not shown until call
Taiwan
+81 704 336 2XXX
N/A
✅ Shown immediately
Questions
How should numbers be formatted or stored in the Call Directory patterns so that they match both incoming calls and dialer input consistently across regions?
Are there region-specific number normalization rules (e.g., Japan’s 0-prefixed local dialing or Taiwan’s international format handling)?
Is there an official guideline or recommendation for formatting phone numbers in Call Directory extensions (e.g., E.164 vs local format) to ensure consistent matching?
Notes
The inconsistent behavior appears to be related to how iOS normalizes numbers per carrier region and local dialing conventions.
In Japan, incoming calls from mobile numbers starting with 070 match correctly, while 0120 (toll-free) fails unless entered in local format.
Hi, We are working to integrate the Live Caller ID Lookup feature into our app.
After submitting the request form via the link: https://developer.apple.com/contact/request/live-caller-id-lookup/, we received this reply from Apple:
Apple’s OHTTP relay has been configured to talk to your OHTTP gateway. Now Live Caller ID Lookup should work for your application extension when distributed through App Store.
However, before officially releasing our app on the App Store, we’d like to make sure the Live Caller ID Lookup feature is working as expected.
To test this, we uploaded the app to TestFlight, and it successfully passed App Review.
However, the test failed — we observed that the system tries to fetch the config from http://www.example.com/config instead of our actual configuration URL.
Questions:
Is this expected behavior when using TestFlight?
Does the Live Caller ID Lookup feature only become active after full public release on the App Store?
Is there any recommended way to test this feature before public release?
Thank you!
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