I have two call directory extensions, each with InfoPlist.strings in en.lproj and nb.lproj directories. In these files I've defined CFBundleDisplayName for both locales.
These names are displayed under Settings -> Phone -> Call Blocking & Identification. On iOS 12.2 the names are displayed correctly in both Norwegian and English.
Testing on iOS 15.3 the English names are displayed even when device language is set to Norwegian.
Worth noting: When updating the English versions of CFBundleDisplayName this is immediately reflected in Call Blocking & Identification page with Norwegian device language.
As this feature requires a real device, I'm unable to test on iOS 13 and 14.
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
We have started facing an issue after updating Xcode from version 15.2 to 16, we have a voip application with webview and call kit, and we have the Background Modes capabilities: Voip, Audio, Background fetch, and Background processing.
We had no problem on Xcode 15, but ever since updating Xcode 16 and sdk 18, when app goes into the background during an active call, the app is suspended and no events are triggered UNTIL the app is resumed to the foreground.
As the title says.
This happens even when not in dark mode.
Hello,
I recently created an app with the Calldirectory Extension. It worked all good as long as I was on my development iphone. I tried to install the app on my privat iphone (same phone/same os version), but then I faced an issue. I couldn't enable the Calldirectory Extension with an error
(Error Enabling Extension
Failed to request data for APPNAME. You may try enabling the extension again, and if the problem persists, conatact the application developer.)
Steps to Reproduce
make an outbound call
cover the sensor
Actual Behavior
the screen won't go dark
device iOS Result
iphone15 17 Pass
iphone14p 18.0.1 Pass
iphoneXs_pro max 18.1.1 Pass
iphone13pro max 18.2.1 Pass
iphone16pro 18.2 Fail
iphone15pro max 18.3 Fail
iphone12 pro max 18.3 Fail
ps: Skype has the same probelm
Seems like this issue only happens on iOS18.2+ on some devices, so is there a bug for this?
i am seeing a call icon on CallKit incoming call screen for a PushKit-initiated call (without caller information like name or number)
Hi Apple Dev Team,
We have a React Native application that includes call functionality using PushKit and VoIP notifications.
We are using APNS to send the VoIP notifications, and everything has been working smoothly on iOS versions up to 18.3.1.
However, after updating to iOS 18.4, we are no longer receiving incoming VoIP push notifications on the device.
There have been no code changes related to our PushKit or notification logic — the exact same build continues to work correctly on devices running iOS 18.3.1 and earlier.
We're trying to understand if anything has changed in iOS 18.4 that affects VoIP push delivery or registration behavior.
Would appreciate any guidance, and happy to share code snippets or configuration if needed.
Thanks in advance!
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 have a question about the default calling function that is supported by third-party apps on iOS from 18.2.
In most cases, it works normally with the default calling app setting, but the problem occurs when connected to the vehicle via Bluetooth.
Install the app that sets the default calling app on the device.
Keep the phone locked.
Connect the Bluetooth to the vehicle.
Try to make a call using the phone button on the vehicle's steering wheel.
When trying to make a call from the vehicle, the call fails (It seems that the app cannot be opened when the phone is locked even if the default calling app setting is on.)
When you unlock the phone and turn on the app, the call is made.
As far as I understand, if the app scheme is called with tel:// when set as the default calling app, it only proceeds with the intent connection to the app set as the default calling app, and the permissions that Apple's default call app has cannot be used.
Accordingly, my questions are as follows:
Is there a way to make a call with an external phone call input when locked on device?
If 1 is not possible, can you provide a branch to Apple's default call app (telephony://) in the above situation?
What I want to achieve now is that when the app is not running, upon receiving a notification, it displays an interface similar to CallKit with accept and decline buttons.
Here is part of my code:
@available(iOS 17.4, *)
class LiveCommunicationManager: NSObject, ConversationManagerDelegate {
static let shared = LiveCommunicationManager()
var isInvalidate:Bool = false
var configuration: ConversationManager!
override init() {
let config = ConversationManager.Configuration(
ringtoneName: "notes_of_the_optimistic",
iconTemplateImageData: UIImage(named: "AppIcon")?.pngData(), // 图标的 PNG 数据
maximumConversationGroups: 1, // 最大对话组数
maximumConversationsPerConversationGroup: 1, // 每个对话组内最大对话数
includesConversationInRecents: false, // 是否在通话记录中显示
supportsVideo: false, // 是否支持视频
supportedHandleTypes: [.generic,.phoneNumber,.emailAddress] // 支持的通话类型
)
configuration = ConversationManager.init(configuration: config)
}
func reportIncomingCall(uuid: UUID, callerName: String) {
configuration.delegate = self
let local = Handle(type: .generic, value: callerName, displayName: callerName)
let update = Conversation.Update(localMember: local,members: [local],activeRemoteMembers: [local])
Task{
do {
try await configuration.reportNewIncomingConversation(uuid: uuid, update: update)
print("成功报告新来电")
} catch {
print("报告新来电失败: \(error.localizedDescription)")
}
}
}
func conversationManager(_ manager: ConversationManager, conversationChanged conversation: Conversation) {
print("会话状态改变了")
}
func conversationManagerDidBegin(_ manager: ConversationManager) {
print("会话已经开始了")
manager.delegate = self
}
func conversationManagerDidReset(_ manager: ConversationManager) {
print("会话将要清除了")
}
func conversationManager(_ manager: ConversationManager, perform action: ConversationAction) {
print("会话接听了")
configuration.invalidate()
}
func conversationManager(_ manager: ConversationManager, timedOutPerforming action: ConversationAction) {
print("会话超时了")
}
func conversationManager(_ manager: ConversationManager, didActivate audioSession: AVAudioSession) {
print("会话激活了")
}
func conversationManager(_ manager: ConversationManager, didDeactivate audioSession: AVAudioSession) {
print("会话死亡了")
}
}
在Appdelegate里设置了这些:
func application(_ application: UIApplication,
didReceiveRemoteNotification userInfo: [AnyHashable: Any],
fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {
// 在这里处理离线推送通知
completionHandler(.noData) // 返回后台任务完成
if let aps = userInfo["aps"] as? [String: Any],
let alert = aps["alert"] as? [String : Any]{
// 静默推送的处理逻辑
if #available(iOS 17.4, *) {
let manager = LiveCommunicationManager.shared
if manager.isInvalidate { return }
if let msgType = userInfo["msgType"] as? Int{
if msgType == 5{
manager.configuration.invalidate()
}else{
let callerName = alert["title"] as? String ?? "Fanvil"
manager.reportIncomingCall(uuid: UUID(), callerName: callerName)
}
}
}
}
}
Xcode has been configured with the necessary capabilities, such as Background Fetch, Voice over IP, Background Processing, and Push Notification.
The issue now is that sometimes the code works as expected, allowing the app to wake up when not running and displaying the system interface with accept and decline buttons. However, after a few successful attempts, the app stops waking up, and no notification appears. But when I manually open the app, the didReceiveRemoteNotification method gets triggered.
I’d like to know why this stops working after a few times.
I am developing a system to send VoIP notifications to terminals with APNs.
I understand that the maximum JSON Payload for VoIP is 5kb.
If I want to send VoIP notifications to 3000 terminals, I am considering sending 3000 requests in parallel from the system to the APNs, will the APNs guarantee that the notifications will be sent to each terminal without a significant time lag when receiving 3000 requests simultaneously?
Hi, Team.
We are currently creating a VoIP calling app using pjsip and want to be able to handle 4 calls at the same time. It is also necessary to be able to notice calls that are on hold or have not answered yet in hands-free (without looking the screen).
However, It seems like CallKit has the intention to silence the ringtone when multiple calls come in.
Problem
What does actually happen?
If a second call comes in while the first one have not answered yet, CallKit screen keeps showing about the first one.
If tapped "Accept" button, the second call ends.
If tapped "Decline" button, CallKit screen shows about the second call at last.
If the first call has put on hold before the second one comes in, CallKit screen shows "Hold & Accept" button even though the first call is already on hold.
When "Hold & Accept" button is displayed, ringtones and other sounds from app stop.
When tapped "Hold & Accept" button for the second call and then unhold the first one in provider(_ provider: CXProvider, perform action: CXAnswerCallAction), ringtone of the first call doesn't ring.
What is expected to happen?
If a second call comes in while the first one have not answered yet, CallKit screen shows about the second call.
If tapped "Accept" button, the second call starts and the first call is displayed on CallKit screen.
If tapped "Decline" button, the first call appears again.
If the first call has put on hold before the second one comes in, CallKit screen shows only "Accept" and "Decline" button (not in full screen).
If a second call comes in while the first one have not answered yet, ringtones continue to ring.
When accepted the second call, ringtone of the first call rings again.
Information
Sample code
Using CallKit to simulate three incoming calls and two alarm notifications.
Whether or not the first call is put on hold before the second one comes in is switchable from the bottom menu.
https://github.com/ryu-akaike/CallKit-Multiple-Incoming-Test
Versions
macOS: Sequoia 15.1
Xcode: 16.2
iPhone: 11
iOS: 18.1.1
Thank you.
Ryu Akaike
Good day
We developed a simple swift code to make the device ringing when a certain type of notifications arrives from our backend. This is the code:
let phoneNumber = CXHandle(type: .generic, value: (self.userInfoForPluginCall!["data"] as! [String:Any]) ["caller"] as! String)
callUpdate.remoteHandle = phoneNumber
let configuration = CXProviderConfiguration(localizedName: "Trec Conf")
configuration.maximumCallGroups = 1
configuration.maximumCallsPerCallGroup = 1
configuration.supportsVideo = false
configuration.supportedHandleTypes = [.generic]
configuration.iconTemplateImageData = UIImage(named: "callkit-icon")?.pngData()
let callProvider = CXProvider(configuration: configuration)
callProvider.setDelegate(self, queue: nil)
callProvider.reportNewIncomingCall(with: callUUID!, update: callUpdate, completion: {error in})
We are noticing some problems on the call screen: on certain devices (iOS 18.4RC) the normal call screen appears and the user can answer or decline the call, on other devices (iOS 18.3, especially with dynamic island) only a phone icon appears in the upper right corner and no possibility to answer or deny call.
Any idea on why we are encountering that behavior?
Thanks
I am working on an iOS app using Flutter that tracks outgoing calls using CallKit. The call tracking functionality works perfectly in Debug mode but does not work when the app is published to TestFlight.
I have already added Background Modes (voip, audio, processing, fetch) in Info.plist. I have added CallKit.framework in Xcode under Link Binary With Libraries (set to Optional).
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>aps-environment</key>
<string>production</string>
</dict>
</plist>
These are the necessary permission which I used in info.plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>BGTaskSchedulerPermittedIdentifiers</key>
<array>
<string>com.agent.mygenie</string>
</array>
<key>CADisableMinimumFrameDurationOnPhone</key>
<true/>
<key>CFBundleDevelopmentRegion</key>
<string>$(DEVELOPMENT_LANGUAGE)</string>
<key>CFBundleDisplayName</key>
<string>MyGenie</string>
<key>CFBundleDocumentTypes</key>
<array/>
<key>CFBundleExecutable</key>
<string>$(EXECUTABLE_NAME)</string>
<key>CFBundleIdentifier</key>
<string>$(PRODUCT_BUNDLE_IDENTIFIER)</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>mygenie</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleShortVersionString</key>
<string>$(FLUTTER_BUILD_NAME)</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleVersion</key>
<string>$(FLUTTER_BUILD_NUMBER)</string>
<key>LSRequiresIPhoneOS</key>
<true/>
<key>NSCallKitUsageDescription</key>
<string>This app needs access to CallKit for call handling</string>
<key>NSContactsUsageDescription</key>
<string>This app needs access to your contacts for calls</string>
<key>NSMicrophoneUsageDescription</key>
<string>This app needs access to microphone for calls</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>This app needs access to photo library for profile picture updation</string>
<key>UIApplicationSupportsIndirectInputEvents</key>
<true/>
<key>UIBackgroundModes</key>
<array>
<string>voip</string>
<string>processing</string>
<string>fetch</string>
<string>audio</string>
</array>
<key>UILaunchStoryboardName</key>
<string>LaunchScreen</string>
<key>UIMainStoryboardFile</key>
<string>Main</string>
<key>UISupportedInterfaceOrientations</key>
<array>
<string>UIInterfaceOrientationPortrait</string>
<string>UIInterfaceOrientationLandscapeLeft</string>
<string>UIInterfaceOrientationLandscapeRight</string>
</array>
<key>UISupportedInterfaceOrientations~ipad</key>
<array>
<string>UIInterfaceOrientationPortrait</string>
<string>UIInterfaceOrientationPortraitUpsideDown</string>
<string>UIInterfaceOrientationLandscapeLeft</string>
<string>UIInterfaceOrientationLandscapeRight</string>
</array>
[code.txt](https://developer.apple.com/forums/content/attachment/0a327dbd-652e-41d5-8811-c462d09e0567)
</dict>
</plist>
And below is the file are AppDelegate.swift, call_tracking_mixin.dart, & main_call.dart file for full knowledge
Hi everyone,
We're experiencing an issue with our Flutter app that uses PushKit, CallKit, and Janus for handling VoIP calls. Everything works fine when the app is in the foreground, but when the app is in the background or completely closed (terminated state), the behavior is inconsistent:
Sometimes, incoming calls are received as expected.
Other times, the app does nothing, and the call is not delivered at all.
Upon checking the console logs, we noticed that our app is being canceled (terminated by the system), which seems to be the reason why calls are not coming through. This happens randomly, making it difficult to reproduce consistently.
Additional Details:
The app is configured to handle VoIP notifications correctly.
We are using PushKit to wake up the app and trigger CallKit for the incoming call UI.
When the app is active, calls are handled correctly via Janus WebRTC signaling.
We have verified that background modes for VoIP are enabled in the Info.plist.
We suspect that iOS may be aggressively killing the app in the background, preventing incoming call notifications from reaching it.
Questions:
Has anyone experienced similar behavior with PushKit + CallKit on recent iOS versions?
Could iOS be terminating the app due to background execution policies?
Are there recommended best practices to ensure reliable delivery of VoIP notifications when the app is closed?
Any insights or suggestions would be greatly appreciated!
Thanks!
Addional Information:
this is the cancellation information at console: Received incoming message on topic hiperme.app at priority 10
por omisión 17:10:18.462084-0300 dasd CANCELED: com.apple.pushLaunch.hiperme.app:E8BACD at priority 10
Hello, experts!
I'm working on a VOIP application that handles audio calls and integrates with CallKit. The problem occurs when attempting to redial a previously made audio call from the system's call history. When I try to handle the NSUserActivity in the application(_:continue:restorationHandler:) method, it intercepts the INStartAudioCallIntent instead of the expected INStartCallIntent.
Background
Deprecation Warnings: I'm encountering deprecation warnings when using INStartAudioCallIntent and INStartVideoCallIntent:
'INStartAudioCallIntent' was deprecated in iOS 13.0: INStartAudioCallIntent is deprecated. Please adopt INStartCallIntent instead.
'INStartVideoCallIntent' was deprecated in iOS 13.0: INStartVideoCallIntent is deprecated. Please adopt INStartCallIntent instead.
As a result, I need to migrate to INStartCallIntent instead, but the issue is that when trying to redial a call from the system’s call history, INStartAudioCallIntent is still being triggered.
Working with Deprecated Intents: If I use INStartAudioCallIntent or INStartVideoCallIntent, everything works as expected, but I want to adopt INStartCallIntent to align with the current iOS recommendations.
Configuration:
CXProvider Configuration: The CXProvider is configured as follows:
let configuration = CXProviderConfiguration()
configuration.supportsVideo = true
configuration.maximumCallsPerCallGroup = 1
configuration.maximumCallGroups = 1
configuration.supportedHandleTypes = [.generic]
configuration.iconTemplateImageData = UIImage(asset: .callKitLogo)?.pngData()
let provider = CXProvider(configuration: configuration)
Outgoing Call Handle: When making an outgoing call, the CXHandle is created like this:
let handle = CXHandle(type: .generic, value: callId)
Info.plist Configuration: In the info.plist, the following key is defined:
<key>NSUserActivityTypes</key>
<array>
<string>INStartCallIntent</string>
</array>
Problem:
When trying to redial the audio call from the system's call history, the NSUserActivity received in the application(_:continue:restorationHandler:) method is an instance of INStartAudioCallIntent instead of INStartCallIntent. This happens even though INStartCallIntent is listed in NSUserActivityTypes in the info.plist and I want to migrate to the newer intent as recommended in iOS 13+.
Device:
iPhone 13 mini
iOS version 17.6.1
Topic:
App & System Services
SubTopic:
Automation & Scripting
Tags:
Foundation
CallKit
Intents
App Intents
Is CallKit still not available in certain countries? like China? If it is, is there a way to get a list of countries?
Hello.
We're developing an app with Flutter that receives VoIP calls. However, when the app is in the background or closed, the push notification arrives, but the call doesn't. It works perfectly when the app is open. We use Firebase, Flutter, and JANUS WebRTC. We need to know what type of permissions or actions we should consider so that the app opens when it receives a call. How can we resolve this issue? Thank you very much.
I am developing "local push" VoIP application.
I have a question about issues I found while testing this app.
After repeating a test for 24 hours in which a incoming call followed by an immediate disconnect 0.1 seconds later,
the iPhone of incommig call side encountered a 0xBAADCA11 error, causing iOS to force-close the app.
(The incidence is low, occurring three times in 17280 times incoming call(24 hours.))
This problem found on iOS17.6.1 (iPhone11Pro).
When the same test was performed on iOS18.2 (iPhoneSE3), the problem did not occur.
Did iOS take something measures against the 0xBAADCA11 error between iOS17.6.1 and iOS18.2?
If yes, I want to encourage customers to upgrade to the latest iOS version, please tell me about it?
※I have attached an ips files and sysdiagnose file of the 0xBAADCA11 error occurring. (please refer sysdiagnose also if you need.)
FjSoftPhone-2025-01-16-113049.ips
FjSoftPhone-2025-01-16-175253.ips
FjSoftPhone-2025-01-17-070449.ips
[sysdiagnose_2025.01.17_14-24-48+0900_iPhone-OS_iPhone_21G93.tar.gz]
https://drive.google.com/file/d/1CV8laKzdnQxvwaAIOwMcXL8rAYL2jq35/view?usp=sharing
Hello,
I am developing a calling service using CallKit and VOIP push.
I have occasionally encountered a strange issue.
The issue is that VOIP permanently fails to receive calls.
I was previously informed that even if the device is blocked, it can receive calls again after 24 hours.
Also, when I checked the device logic, it complied with the policy requirements set by Apple, including correctly calling CallKit's reportNewIncomingCall method.
Once the issue occurs, no matter how many times I try, VOIP does not receive calls, and neither a device reboot nor checking the Device Console Log shows any logs related to CallKit or VOIP.
I suspect this might be an issue with the VOIP token, and I believe that the only way to get a new one is to reinstall the app. Is that correct?
Of course, after reinstalling, it works fine again, but this is very inconvenient. I don't think this is the right solution.
Is there anyone who can share their insights on this issue?
Thank you.