Hello, I’m implementing VoIP calling in an iOS application using PushKit (VoIP pushes) together with CallKit. The standard call flow works correctly: Happy scenario User A initiates a call. Server sends a VoIP push to User B. User B’s device receives the push and reports the incoming call using CallKit. User B answers the call. However, I would like clarification about non-happy scenarios and when it is acceptable to use VoIP pushes to update or stop a CallKit ringing state. Apple documentation warns that VoIP pushes must be used only when they result in a call-related action, so I want to ensure the following cases are compliant. Scenario A — Caller Cancels Before Answer User A calls User B. Server sends a VoIP push to User B. User B’s device starts ringing via CallKit. Before User B answers, User A cancels the call. Question: Is it acceptable to send another VoIP push to User B indicating that the call has been cancelled so the device can: stop the CallKit ringing UI end the call optionally mark it as missed or cancelled Or should this state change be handled using a regular remote push or another signaling mechanism instead of VoIP push? Scenario B — Callee Rejects the Call User B rejects the call from CallKit. The server must inform User A that the call was rejected. Question: Is it acceptable to send a VoIP push to User A to update the CallKit state and terminate the outgoing call UI? Scenario C — Multiple Devices per User User B may be logged in on multiple devices. User A calls User B. VoIP push is sent to all devices of User B. One device answers. Question: Is it acceptable to send a VoIP push to the remaining devices instructing them to: stop ringing end the CallKit incoming call UI Or is there a recommended alternative pattern for this case? Main Question Aside from the initial incoming call VoIP push, in which situations is it considered acceptable to send additional VoIP pushes to terminate or update CallKit state (cancelled, rejected, answered on another device)? The goal is to remain compliant with PushKit policies, particularly the guidance that VoIP pushes should only be used when they result in a call-related user action. Any guidance on the recommended architecture for these cases would be greatly appreciated. Thank you.

Hello, We're seeing a high rate of providerDidReset callbacks in production across a large user base (iOS 16, 17, 18, and 26). I'd like to understand both the correct way to handle this delegate method and strategies to reduce its frequency. Background The callback occurs across all iOS versions we support and is not isolated to a specific device or region. The callback can occur in any app state (foreground, background, inactive), however it is most dominant in the background state — particularly during VoIP push notification handling. The callback is more prevalent during long app sessions — for example, when the app has been running continuously for a day or overnight. We do not call CXProvider.invalidate() anywhere in our codebase explicitly. After providerDidReset fires, subsequent transactions fail with CXErrorCodeRequestTransactionErrorUnknownCallUUID (error code 4). Re-initializing the provider via initializeProvider() resolves this error. Our Implementation We use a singleton proxy class (CallKitProxy) that owns the CXProvider. Below is a simplified version — some logging and non-essential parts have been removed for brevity. @objcMembers public final class CallKitProxy: NSObject { private var cxProvider: CXProvider? private let cxCallController: CXCallController private let cxCallObserver: CXCallObserver private override init() { cxCallObserver = CXCallObserver() cxCallController = CXCallController() super.init() initializeProvider() cxCallObserver.setDelegate(self, queue: nil) } private func initializeProvider() { let configuration = providerConfiguration() cxProvider = CXProvider(configuration: configuration) cxProvider?.setDelegate(self, queue: nil) } private func providerConfiguration() -> CXProviderConfiguration { let soundName = SharedUDHelper.shared.string(forKey: .pushNotificationSoundNameForCall) let sound = CallNotificationSounds(name: soundName ?? "ringtoneDefault") let configuration = CXProviderConfiguration() configuration.supportsVideo = true configuration.maximumCallsPerCallGroup = 1 configuration.maximumCallGroups = 1 configuration.supportedHandleTypes = [.phoneNumber, .generic] configuration.iconTemplateImageData = UIImage( named: "callkit_mask", in: .main, compatibleWith: nil )?.pngData() configuration.ringtoneSound = sound.name return configuration } public func requestTransaction( action: CXCallAction, completion: @escaping (Error?) -> Void ) { let transaction = CXTransaction(action: action) cxCallController.request(transaction) { error in completion(error) } } } extension CallKitProxy: CXProviderDelegate { public func providerDidReset(_ provider: CXProvider) { // End any active calls, then re-initialize the provider initializeProvider() } } Questions 1. Is re-initializing the provider inside providerDidReset the correct approach? The documentation states that providerDidReset signals the provider has been reset and all calls should be considered terminated. Should we be calling CXProvider.invalidate() on the old instance before creating a new one? Or is assigning a new CXProvider to cxProvider (which releases the old instance) sufficient? 2. What could be causing providerDidReset to fire so frequently, and how can we reduce it? We're particularly concerned about cases triggered during VoIP push handling in the background and inactive states. Are there known conditions — such as provider configuration changes, app lifecycle events, or system memory pressure — that commonly trigger this callback? And are there any recommended patterns to make the provider more resilient in these scenarios? Thank you.

Hi! We’ve had Live Caller ID Lookup in production for a while. We’re seeing backend RPS on our /queries endpoint much higher than our expected incoming call volume. While testing with Console.app during an incoming call, it looks like iOS may still hit our service even when the caller number is already in the user’s Contacts - but I’m not 100% sure from logs alone. Can you confirm: Does iOS invoke Live Caller ID Lookup (i.e. call /queries) for every incoming call, including calls from saved Contacts? If yes, is this simply expected framework behavior? Thanks!

If an iPhone receives an incoming call with some partial sip content (for example it contains a name but not an image, or vice versa) and if there is an app enabled for Live Caller ID Lookup, and the result of that lookup supplies data not in the sip (i.e. the lookup returns an image, but not a name, or vice versa). Then could the OS combine data from both sources, or is whatever is returned from the LCIDL what gets displayed in the call screen. I suppose that is the case but just want to enquire to make sure. Thank you

iOS App terminated by Watchdog (Signal 9) in Background state despite reporting call Description I have successfully implemented VoIP pushes for the Killed state, where CallKit triggers correctly. However, when the app is in the Background state (suspended), it consistently crashes with an NSInternalInconsistencyException. The app process is killed by the iOS Watchdog because it fails to satisfy the requirement of posting an incoming call in the same run loop as the push receipt, or the completion handler is not being released fast enough by the JS bridge. Environment React Native Version: .78 React Native CallKeep Version: 4.3.14 React Native VoIP Push Notification Version: 3.3.3 iOS Version: 18.x Device: Physical iPhone [iphone 13 pro] The Issue When a VoIP push arrives while the app is in the Background: pushRegistry:didReceiveIncomingPushWithPayload: is called. RNCallKeep.reportNewIncomingCall is triggered on the Main Thread. The app is terminated by the system before the CallKit UI is fully established or before the completion() closure is executed. Current Implementation (AppDelegate.swift) func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType, completion: @escaping () -> Void) { let payloadDict = payload.dictionaryPayload let callerName = payloadDict["callerName"] as? String ?? "Unknown Caller" let callUUIDString = payloadDict["uuid"] as? String ?? UUID().uuidString let userGUID = payloadDict["guid"] as? String ?? "0" RNCallKeep.reportNewIncomingCall( callUUIDString, handle: userGUID, handleType: "generic", hasVideo: false, localizedCallerName: callerName, supportsHolding: true, supportsDTMF: true, supportsGrouping: true, supportsUngrouping: true, fromPushKit: true, payload: ["userGuid": userGUID], withCompletionHandler: { } ) RNVoipPushNotificationManager.didReceiveIncomingPush(with: payload, forType: type.rawValue) completion() } Logs Exception Type: EXC_CRASH (SIGKILL) Exception Note: EXC_CORPSE_NOTIFY Termination Reason: TCC 1 | [CoreFoundation] Killing app because it never posted an incoming call to the system after receiving a PushKit VoIP push. Observed Behavior Killed State: Works perfectly. Foreground State: Works perfectly. Background State: The phone may vibrate once, but the app process is killed before the CallKit UI appears. Questions/Suspected Causes Is RNVoipPushNotificationManager.addCompletionHandler causing a delay in the background run loop that triggers the Watchdog? Should completion() be called immediately in Swift for the Background state, rather than waiting for VoipPushNotification.onVoipNotificationCompleted in JS? Is there a known issue with RNCallKeep not being able to present the UI while the app is in a suspended background state?

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

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

Starting in iOS 26.4, PushKit has introduced a new "didReceiveIncomingVoIPPushWithPayload" delegate, making it explicit whether or not an app is required to report a call for any given push. The new delegate passes in a PKVoIPPushMetadata object which includes a "mustReport" property. We have not documented the exact criteria that will cause a mustReport to return false, but those criteria currently include: The app being in the foreground at the point the push is received. The app being on an active call at the point the push is received. The system determines that delivery delays have made the call old enough that it may no longer be viable. When mustReport is false, apps should call the PushKit completion handler (as they previously have) but are otherwise not required to take any other action. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Dear Apple Support Team, Thank you for your continued support. I would like to inquire about the behavior of CallKit. Our company provides an office PBX extension phone application (iPhone app). When the iPhone is placed into sleep mode (screen off) and our app receives an incoming call, the following sequence sometimes results in an audio playback panel appearing at the bottom of the lock screen for a few seconds after the call ends(See attachment file for detail). Sequence to reproduce the issue: Put the iPhone into sleep mode (screen off). Receive an incoming call to our extension phone app. CallKit incoming call screen appears. Answer the call. Conduct the call. End the call from the peer. iOS versions with confirmed behavior: iOS 26.0: Not observed. iOS 26.2: Observed. iOS 26.3: Not observed. This behavior does not affect the call functionality itself; however, some users report that the temporary appearance of the audio playback panel feels unusual. If there is any known reason for this behavior or any recommended workaround, we would greatly appreciate your guidance. Additionally, if this is a known issue that was addressed in iOS 26.3, we would appreciate any information you can provide regarding that as well. Thank you very much for your assistance.

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?

When Live Caller ID first came out I experimented with it and got it working using the Example PIR database. All my links from that time are now out of date and no longer work, however I seem to have found where the PIR database example and documentation has moved to (https://swiftpackageindex.com/apple/pir-service-example/main/documentation/pirservice/testinginstructionslivecalleridlookup) But what I can't find is an exact definition of the the logo size/max size/dimensions/format should be. My memory from that time is that it was very pernickety, and if things weren't exactly right, the logo wasn't displayed. I can remember the format had to be HEIC to get it to work. Looking through the documentation however, I can't see exact requirements specified. My question is - for the Live Caller ID logo what are the exact image requirements, and where are they documented?

Hello, I am developing an internal phone application using CallKit. I am experiencing an issue with the behavior of remoteHandle settings in iOS 26 and would appreciate any insights you can provide towards a solution. 1. Problem Description When an iPhone running iOS 26 is in a sleep state and receives a VoIP incoming call where remoteHandle is set to nil or an empty string (@""), we are unable to transition to our application (the UIExtension provided by the provider) from the CallKit UI's "More" (…) button after answering the call. 2. Conditions and Symptoms OS Version: iOS 26 Initial State: iPhone is in a sleep state Call Type: An unsolicited(unknown number) VoIP incoming call where the CXCallUpdate's remoteHandle is set to either nil or [[CXHandle alloc] initWithType:CXHandleTypePhoneNumber value:@""] Symptoms: After answering the VoIP call by sliding the button, selecting the "More" (…) button displayed on the CallKit screen does not launch our application's UIExtension (custom UI), and the iPhone instead stay to the CallKit screen. 3. Previous Behavior (Up to iOS 18) Up to iOS 18, even when remoteHandle was set to an empty string using the following code, the application would transition normally from "More" after answering an incoming call from a sleep state. CXCallUpdate *update = [[CXCallUpdate alloc] init]; update.remoteHandle = [[CXHandle alloc] initWithType:CXHandleTypePhoneNumber value:@""]; [provider reportNewIncomingCallWithUUID:uuid update:update completion:completion]; 4. Unsuccessful Attempts to Resolve The issue remained unresolved after changing the handling for unsolicited(unknown number) incoming calls as follows: CXCallUpdate *update = [[CXCallUpdate alloc] init]; update.remoteHandle = nil; // Set remoteHandle to nil [provider reportNewIncomingCallWithUUID:uuid update:update completion:completion]; 5. Workaround (Temporary) The problem can be resolved, and the application can transition successfully, by setting a dummy numerical value (e.g., "0") for the value in remoteHandle using the following code: CXCallUpdate *update = [[CXCallUpdate alloc] init]; update.remoteHandle = [[CXHandle alloc] initWithType:CXHandleTypePhoneNumber value:@"0"]; // Set a dummy numerical value [provider reportNewIncomingCallWithUUID:uuid update:update completion:completion]; 6. Additional Information If remoteHandle is correctly set with the caller's number (i.e., not an unsolicited(unknown number) call; e.g., value:@"1234567890"), the application transitions normally from the "More" button after answering an incoming call from a sleep state, even in iOS 26. The above issue does not occur when answering incoming calls while the iPhone is in an active state (not sleeping). 7. Questions Have there been any other reports of similar behavior? Should this be considered a bug in CallKit for iOS 26? Should I make file a new Feedback report? Is there a suitable method to resolve this issue when the caller ID is unsolicited (nil or an empty string)? This problem significantly impacts user operations as end-users are unable to perform essential in-app actions such as hold or transfer after answering an unsolicited(unknown number) call from a sleep state. We are eager to find an urgent solution and would appreciate any information or advice you can provide. Thank you for your assistance.

Hi, happy new year, I'm a Product Manager for a communications app that's currently in testflight. We requested the com.apple.developer.usernotifications.filtering entitlement on December 3rd, and have yet to receive a response from Apple. I understand that the holiday break may have gotten in the way, however it feels like we were lost in the queue as it's been 6 weeks with no response. Our app owner has checked-in inside appstoreconnect but has not received anything back. Is this common? Is there any process for getting a status update? Are we doing something wrong? Without this entitlement we cannot make the device ring in the background. The app is a voice and video messaging platform.

Hi all, I'm working on a Call Directory Extension using CXCallDirectoryExtensionContext. I want to add a list of numbers to be blocked. Here's the function I use: override func beginRequest(with context: CXCallDirectoryExtensionContext) { context.delegate = self let blockedNumbers = loadNumberEntries(forKey: blockedKey) let identifiedNumbers = loadNumberEntries(forKey: identifiedKey) addAllBlocking(blockedNumbers, to: context) addAllIdentification(identifiedNumbers, to: context) context.completeRequest() } private func addAllBlocking(_ entries: [NumberEntry], to context: CXCallDirectoryExtensionContext) { let numbers: [Int64] = entries.compactMap { Int64($0.countryCode + $0.phone) }.sorted() for number in numbers { context.addBlockingEntry(withNextSequentialPhoneNumber: number) print("# Added blocking entry: \(number)") } } When I run this, I see in the console: # Added blocking entry: (*my number with country code*) So it seems the number is added correctly. However, in practice, the number is not blocked on the device. I’ve made sure that: The number is stored with the country code prefix. The extension is enabled in Settings → Phone → Call Blocking & Identification. The extension is reloaded after adding numbers. The array of numbers is sorted in ascending order before calling addBlockingEntry. Despite all this, the number still isn’t blocked. Does anyone know why the print shows the number added, but it doesn’t actually block the call? Am I missing something in the way CXCallDirectoryExtensionContext works? Thanks for any advice!

In my application, I use CallKit and have supportsHolding = true set. During my phone call, another call comes in (e.g., GSM). I accept the incoming call and put the current call on hold. If I end the active call myself, everything is fine, and CallKit calls the method provider(_ provider: CXProvider, didActivate audioSession: AVAudioSession). However, if the other party ends the call, the second call remains on hold. In the application, the user clicks on unhold, and I notify CallKit that the hold has ended. But in this case, the didActivate method is not called at all. If I try to activate the audio myself after unhold, I receive the error: Domain=NSOSStatusErrorDomain Code=561017449 "Session activation failed" UserInfo={NSLocalizedDescription=Session activation failed} AVAudioSessionErrorInsufficientPriority == NSOSStatusErrorDomain Code: 561017449 What needs to be done for CallKit to activate my audio?

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 am facing a severe audio routing instability issue when using CallKit and the Zego Express SDK on iOS. The problem is that the audio route immediately reverts from the Speaker back to the Earpiece, effectively disabling the Speaker button functionality.📝 Observed BehaviorWhen the user taps the native CallKit Speaker Button, the audio route is correctly changed to the Speaker, but then instantly flips back to the Receiver (Earpiece), as shown in the system log captured via AVAudioSession.routeChangeNotification monitoring.🧾 Log Evidence (Flapping Occurs in 0.4 seconds)The following log snippet clearly illustrates the system overriding the user's action (reason: 4) with an unexpected CategoryChange (reason: 3) event: TimestampComponentReason CodeDescriptionRouteIs Speaker16:31:18.009[CallKitManager]4Override (CallKit/ControlCenter)Loa ngoài (Speaker)true16:31:18.411[CallKitManager]3CategoryChangeThiết bị nhận (Receiver)false

Hello, colleagues. I am reaching out to the community with an issue that is likely quite common. Unfortunately, I have not been able to resolve it independently and would like to confirm if my approach is correct. Core Problem: VoIP push notifications are not delivered to the application when it is in the background or terminated. After reviewing existing discussions on the forum, I concluded that the cause might be related to CallKit not having enough time to register. However, in my case, I am using AppDelegate, and in theory, CallKit registration should occur quickly enough. Nevertheless, the issue persists. Additional Question: I would also like to clarify the possibility of customizing the CallKit interface. Specifically, I am interested in adding custom buttons (for example, to open a door). Please advise if such functionality is supported by CallKit itself, or if a different approach is required for its implementation. Thank you in advance for your time and attention to my questions. For a more detailed analysis, I have attached a fragment of my code below. I hope this will help clarify the situation. Main File @main struct smartappApp: App { @UIApplicationDelegateAdaptor private var delegate: AppDelegate @StateObject private var navigationManager = NavigationManager() init() { print("Xct") if !isRunningTests() { DILocator.instance .registerModules([ ConfigModule(), SipModule(), AuthModule(), NetworkModule(), CoreDataModule(), RepositoryModule(), DataUseCaseModule(), SipUseCaseModule() ]) } } func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable: Any], fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) { print("Axtest") completionHandler(.newData) } var body: some Scene { App Delegate File class AppDelegate: UIResponder, UIApplicationDelegate { private let voipRegistry = PKPushRegistry(queue: .main) private var provider: CXProvider? func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { setupPushKit() setupCallKit() return true } public func regist(){ setupPushKit() setupCallKit() } private func setupPushKit() { voipRegistry.delegate = self voipRegistry.desiredPushTypes = [.voIP] DispatchQueue.main.async { self.voipRegistry.pushToken(for: .voIP) } } // MARK: - CallKit Setup private func setupCallKit() { let configuration = CXProviderConfiguration(localizedName: "MyApp") configuration.maximumCallGroups = 1 configuration.maximumCallsPerCallGroup = 1 configuration.supportsVideo = true configuration.iconTemplateImageData = UIImage(named: "callIcon")?.pngData() provider = CXProvider(configuration: configuration) provider?.setDelegate(self, queue: .main) } // MARK: - Background Launch Handling func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable: Any], fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) { print("Axtest") completionHandler(.newData) } } extension AppDelegate: PKPushRegistryDelegate { func pushRegistry(_ registry: PKPushRegistry, didUpdate pushCredentials: PKPushCredentials, for type: PKPushType) { APNsImpl().registerToken(token: pushCredentials.token.map { String(format: "%02.2hhx", $0) }.joined()) } func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType) { guard type == .voIP else { return } print("call kit") let payloadDict = payload.dictionaryPayload let update = CXCallUpdate() update.remoteHandle = CXHandle(type: .phoneNumber, value: "dsfsdfddsf") update.hasVideo = payloadDict["hasVideo"] as? Bool ?? false provider?.reportNewIncomingCall(with: UUID(), update: update, completion: { error in if let error = error { print("Failed to report incoming call: \(error.localizedDescription)") } else { print("Successfully reported incoming call") } }) } }

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

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.