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 integration. Put app in background (or kill it). Send a VoIP push. Observe system logs and crash: callservicesd: Delivering 1 VoIP payload(s) to application UrgiDoctor: Apps receiving VoIP pushes must post an incoming call via CallKit... error: Killing VoIP app because it failed to post an incoming call in time. Expected Behavior: On receiving a VoIP push, CallKit UI (Accept / Decline screen) should always appear. App should not be killed if reportNewIncomingCall is called in time. Actual Behavior: CallKit UI never appears in background/killed state. App is force-terminated by iOS before user can accept/decline the call. Request: Guidance on the correct sequence for calling reportNewIncomingCall and completionHandler() in pushRegistry. Clarification if any changes in iOS 17/18 affect PushKit + CallKit behavior. Best practices for ensuring CallKit UI always appears reliably after a VoIP push. Environment: iOS 18.5 Simulator + Device Xcode 16.4 Using PushKit + CallKit with VoIP entitlement

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

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!

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.

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.

Our app receives a CallKit VoIP call. When the user taps “Answer”, the app launches and automatically connects to a real-time audio session using WebRTC or MobileRTC. We would like to confirm whether the following flow (“CallKit Answer → app opens → automatic WebRTC or MobileRTC audio session connection”) complies with Apple’s VoIP Push / CallKit policy. In addition, our service also provides real-time video-class functionality using the Zoom Meeting SDK (MobileRTC). When an incoming CallKit VoIP call is answered, the app launches and the user is automatically taken to the Zoom-based video lesson flow: the app opens → the user is landed on the Zoom Meeting pre-meeting room → MobileRTC initializes immediately. In the pre-meeting room, audio and video streams can already be active and MobileRTC establishes a connection, but the actual meeting screen is not joined until the user explicitly taps “Join”. We would like to confirm whether this flow for video lessons (“CallKit Answer → app opens → pre-meeting room (audio/video active) → user taps ‘Join’ → enter actual meeting”) is also compliant with Apple’s VoIP Push and CallKit policy.

Hello, I recently had an unusual experience, and I’m wondering if this is related to Apple’s policies, so I wanted to ask. While a call is in Picture-in-Picture (PIP) mode, notification pushes from the same app do not appear. The API is being triggered, but the notification banner does not show on the device. Once PIP is closed, the notifications start appearing normally again. Is this behavior enforced by Apple’s policies? What’s interesting is that banners from other apps do appear — only the banners from the app currently in PIP are not shown.

In iOS 26.1, after my app answers a VoIP call on the lock screen, tapping the bottom-left "More" button doesn't bring up the app icon to jump to the app. The same scenario works normally on iOS 26. How can I resolve this issue?

I'm developing a VoIP app. Currently, I'm using CallKit to control call acceptance, and end-of-call processing. When a call comes in while using the phone, CallKit appears as a banner at the top of the screen. When I click "Accept" on the banner, the app opens and the call is received. (For OEMs, clicking the "Accept" button in the banner will accept the call as is.) The reason this feature is needed is, for example, when a call comes in as a banner call while using a navigation app, accepting the call causes the navigation app to go to the back and the VoIP app to come to the foreground, causing inconvenience to customers. This needs to be improved. Please advise.

I’m developing an iOS app that integrates with CallKit. Starting from iOS 26, I’ve noticed that the system automatically presents a top banner / toast-style UI when a CallKit call becomes active (see attached screenshot). This UI appears to be fully managed by the system. On iOS versions prior to iOS 26, this UI did not appear under the same CallKit configuration. What I’ve observed The banner is displayed automatically by the system It appears at the top of the screen, similar to a toast or call status banner It is not a view created by my app I could not find any public API or CallKit configuration related to dismissing or controlling it My questions： Is this top banner an intended system behavior change in newer iOS versions? Is there any public API to dismiss, hide, or customize this UI? If not, is this UI considered non-dismissible by design? Any clarification on the expected behavior or recommended approach would be greatly appreciated.

By analysis the log, seems the following 3 calls has been ended by system callkit (Not mainly trigger the end call): @apple Do you have similar report that the iOS CallKit End the call withtour user action? Device info: iPhone18,1（iPhone 16 Pro） iOS 26.2 RCAppMobile/25.4.30.995 CTRadioAccessTechnologyNR（5G NR）

Hello! I’m building a VoIP app for iPhone and Apple Watch using PushKit and CallKit. I’m trying to understand the recommended watchOS architecture for this kind of setup. What we would like is for the watch to behave as an endpoint for incoming calls, so that when a call comes in the user can answer on either the iPhone or the watch. My understanding is that VoIP notifications are not supported on watchOS, so for incoming calls what we ended up having to do was send the watch a regular APNs alert notification and only start the actual call setup after the user interacts with it. This isn’t ideal, and the notification often appears a few seconds late. What we would like to be able to do is present the incoming call on the watch more like how FaceTime calls appear on Apple Watch. So I wanted to ask whether this is the intended pattern for a companion watchOS VoIP app. Is using a regular APNs alert notification the correct way to surface an incoming call on the watch, or is there a better supported approach? Thanks!

Hi, I have some scenario in which I need to reportIncoming to CallKit with same UUID 2 times. So I just need to know that, it will cause an issue of CallKit or with application.

Hello! https://github.com/apple/live-caller-id-lookup-example/blob/main/Sources/PIRService/PIRService.docc/DataFormat.md The link above shows the data format that the user who gets a call, can get. I wonder if it is also possible to add other fields, for example: "summary". I am currently in the design-phase of an app that aims to present what the last call between the two parties was about, and that information can be gotten from an API that I will build according to Apple's principles that is comaptible with the Live Caller ID Lookup protocol. Therefore adding a field that will present a short summary of the last call will be very handy. Is that possible?

I am developing a VoIP service. Usually, when receiving a VoIP Push, Callkit is exposed immediately after receiving the message and the app is designed to be used. However, there is an extremely intermittent phenomenon (not well reproduced) where the app does not wake up even when receiving a VoIP Push. And after a long time, the app wakes up and Callkit is activated. (A long time after receiving the call…) Has anyone experienced the above phenomenon? I wonder if there are any reported parts depending on the OS version. (I have identified that it does not occur in the 17.x version, but it is difficult to guarantee because it occurs extremely intermittently) The app is not running in the background, but... Could this be happening if there are a lot of pending operations in the background? I need help urgently

Hi, am facing an issue related to voip push notifications getting delivered 1-2 hours after apns-expiration to 0 and apns-priority to 10. I had raised a similar post got a reply that it may be due to network delay. But network delay can cause the delivery of voip push to be delayed only by few seconds or minutes. But in our case voip push is getting delivered hours after the voip call was attempted. Steps to reproduce: Put our voip app in background and lock iPhone. As app is put in background, socket connections gets disconnected from server. Now if a caller makes call to this app, the call should be delivered through voip push. 2) Voip push should ideally be received even if app is in background and iPhone is locked. It is connected to a good wifi network. But it does not receive the voip push. 3) After 1-2 hours user unlocks iPhone and opens voip app. As soon as user opens app, the voip push is received and phone starts ringing.

I am developing a VoIP phone application(Our Phoneapp) using APNs VoIP push. I have a question regarding a behavior I discovered during testing of this application. When performing the following operations using an iPhoneSE3 with an sXGP-NW SIM inserted, 0xBAADCA11 occurs upon receiving an APNs VoIP PUSH. Do you have any information regarding this issue? 0xBAADCA11 occurs in operation 8. However, since there were no problems in operation 4 (the app works when Wi-Fi is off), I think there is no issue with the Our Phoneapp. [Configuration of system components] [VoIP Telephone] --Call to iPhone(Phoneapp)--> [Our VoIP PBX Server] -- VoIP PUSH request --> [Apple APNs Server] -- VoIP PUSH --> [Our Phoneapp (iPhoneSE3(with sXGP SIM)] [Operations] (The issue is reproducible 100% by following oparation) iPhoneSE3: Power on (iPhoneSE3 with sXGP SIM) iPhoneSE3: Wi-Fi off, connect to the internet via SIM. VoIP Telephone: Call to Our Phoneapp iPhoneSE3: Receives VoIP PUSH and Phoneapp launches. Successfully answers the call and communication is possible. (Receives VoIP push notification from APNs via sXGP SIM) iPhoneSE3: Wi-Fi is turned ON, connect to the internet via Wi-Fi. iPhoneSE3: Task kill Our Phoneapp. VoIP Telephone: Call to Our Phoneapp iPhoneSE3: iOS does not call the push notification delegate (didReceiveIncomingPushWithPayload). As a result our Phoneapp is unable to detect the incoming call, However, an ips log with 0xBAADCA11 is output. in other words, iOS received the VoIP PUSH, but Our Phoneapp dose not call CallKit, so Our Phoneapp was terminated by iOS.

We have a problem in a scenario that SIM lock is disabled so after a phone reboots it has the Internet connection but it is still locked. When you call into the VOIP app the app is not being launched as the result (it seems reasonable because it wouldn't be able to access the keychain items etc...) but the OS still seem to enforce the rule that the app needs to report the new incoming call. When we then unlock the app we can see no more pushkit pushes are arriving (dropped on the floor in the console) but we get the three initial pushes that were send during the locked phase right after the app launch.

My app requirement is to check that User is on call while doing transaction. If user on call then we need to show Caution alert. For this requirement we used CallKit to detect Call status and it's working fine but recently Apple has rejected the application because of Callkit that is banned in China. Could you please provide any solution to check the Call Status only.