Hello, I am wondering about developing my application. Can the new commands available with iOS 18 give me access to the call log (recent calls)? With a request prior to installing the application for example. I saw that Truecaller has just launched an update on iOS to offer the same features as Android, i.e. capture the call log. Apple allows applications like Truecaller to integrate their spam databases into the iOS caller ID system. I wonder by which command! Otherwise, I can perhaps use the "SMS and Call Spam Reporting" commands and divert them to retrieve the call log. To tell you the truth, I'm trying to find, for my application, a way to retrieve recent call data to create a call dashboard of certain calls, by retrieving the name or phone number, call date, call time and call duration. Does anyone have an idea?

We’ve encountered significant differences in our VoIP app’s workflow between iOS 17 and iOS 18, particularly on devices with Dynamic Island. Our app functioned as expected in iOS 17 and even iOS 18 on devices without Dynamic Island, but with the public release of iOS 18 on Dynamic Island-supported iPhones, we’re receiving a lot of feedback from users reporting confusing behavior during both incoming and outgoing calls. Here’s a breakdown of the issue: In iOS 17 and iOS 18 (on non-Dynamic Island models), when our app initiates a second call, the app remains in the foreground, allowing the user to see both calls within our UI. Users can manage their calls, swap between them, and even merge them, all without leaving the app. If the user switches to the CallKit controller via the app switcher, it reflects the state of the calls in our app, which has worked well for our users. However, on iOS 18 devices with Dynamic Island, adding a second call now backgrounds our app and brings the CallKit controller UI to the foreground. This causes confusion, as users lose context of managing multiple calls within our app. Though users can switch back to our app manually, this extra step disrupts their workflow, especially when handling multiple active calls. This change doesn't occur on iOS 18 devices without Dynamic Island. Additionally, during an active call, if an incoming call arrives, the Dynamic Island notification takes over, and the app UI is again backgrounded in favor of the CallKit controller screen. Even when declining the incoming call from the notification, the user remains in the CallKit controller UI, requiring another step to return to our app using the app switcher or the "app" button in CallKit. This inconsistent behavior makes call management unnecessarily complex for our users, who need a streamlined experience, especially since our app is used in healthcare communications that is often critical in nature. Is there any documentation on changes to CallKit behavior specific to Dynamic Island devices in iOS 18? We’d appreciate any guidance on designing a VoIP experience that doesn’t involve these disruptive view switches, particularly for Dynamic Island-supported iPhones. Thank you for your help!

Since upgrading to iOS 18, an issue has been observed where blocked incoming calls display "(null)" instead of the actual application name. At the time the calls defined by the same application contain the name of the application correctly.

I am a developer based in Ireland. I updated an iPhone 12 to iOS18.1 Beta 4 in order to investigate the Call Record Feature. We have a VoIP App and I wanted to see if there is any interaction with this new Call Record feature. However there is no option appearing for me under Settings ->Apps->Phone for Call RECORD My suspicion is that this is because I am in Europe and Apple Intelligence is not available here. We have our Apps available in the USA so is there anyway that I can enable Call record for some testing. Alternatively does anybody know if Call record should work with Callkit VoIP Apps?

Hello Apple Developer Community, I'm developing a call-blocking app for iOS and have encountered an issue with iOS 18. Despite calls being successfully blocked by our app's Call Directory extension, they are still appearing as unanswered calls in the native Phone app. Details: iOS version: 18 App uses CallKit and Call Directory extension Calls are blocked successfully (not ringing on device) Blocked calls show up as "Unanswered" in Phone app's recent calls list Expected behavior: Blocked calls should not appear in the Phone app's recent calls list. Actual behavior: Blocked calls appear as "Unanswered" in the recent calls list.

The app declares support for Voice-over IP (VoIP) in the UIBackgroundModes key in your Info.plist, but we are still unable to locate any VoIP services. Apps that declare support for VoIP in the UIBackgroundModes key in your Info.plist file must have features that require VoIP. My app rejected for VOIP and the app is totally supported video call or call when app is terminated or in background how can. i solve that rejection issue

iOS 18 (22A3354) will not offer a option in settings (> Apps > Phone) after calling openSettings to enable live caller id lookup extension. iPhone and MacBook are in the same network. The PIRService runs on MacBook and is reachable via iPhone Safari (via http://MacBookPro:8080/). Hummingbird print log: hb_method=GET hb_uri=/ [Hummingbird] Request. After deploying the application via Xcode to the iPhone no requests are printed in the terminal. The extension was added like documented and bundle id is also checked multiple times. issuerRequestUri in service-config.json is http://MacBookPro:8080/issue. As far as I can tell, everything has been set up in accordance with the Testing Live Caller ID instructions. Is there something missing?

In iOS 18 if a number is registered with CallKit to be blocked, then if that number is also in contacts, then the number isn't blocked. If a user has added a number to their contacts, then in all probability they might not want the number blocked, so this might seem reasonable behaviour. However the point is, this is new behaviour for CallKit in iOS 18, and its never been like this before going back several years to the very first release. Why suddenly change it now, after all these years, without notice nor documentation, and take away that option from the user, should for some reason, they want to block a number which is also in their contacts. This is quite a disruptive change for apps using CallKit.

Hello, I have an app which I have enabled VoIP entitlement and implemented all the CallKit and PushKit registries and delegates. I can successfully get a VoIP token. I can successfully send VoIP push notifications (and receive them via the PushKit delegate function) and then report an incoming call via CallKit, but only while my app is in the foreground. I have checked the entitlement in XCode and the Info.plist directly, and they both (as expected) show voip as a background mode. The VoIP notification is being sent via AWS SNS and everything works while the app is in the foreground. I cannot understand why the app is not waking up while in the background. This is the VoIP notification sent via SNS: aps: { alert: "Intercom call", "content-available": 1 } SNS Message Attributes: 'AWS.SNS.MOBILE.APNS.TOPIC': { DataType: 'String', StringValue: `${bundleId}` }, 'AWS.SNS.MOBILE.APNS.PUSH_TYPE': { DataType: 'String', StringValue: 'voip' }, 'AWS.SNS.MOBILE.APNS_VOIP.TTL': { DataType: 'String', StringValue: '0' }, 'AWS.SNS.MOBILE.APNS_VOIP_SANDBOX.TTL': { DataType: 'String', StringValue: '0' }, 'AWS.SNS.MOBILE.APNS.PRIORITY': { DataType: 'String', StringValue: '10' } As I say, func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType) async works correctly when in the foreground. I cannot see any reason why it would not work from the background. I am also receiving normal remote notifications correctly foreground and background.

Hello everyone, I’m developing a VoIP-based application that supports both standard VoIP calls and Push-To-Talk (PTT) calls. The app does not use the unrestricted-voip entitlement since it’s not publicly documented or communicated as a standard by Apple. Previously, I handled PTT calls using CallKit after receiving PushKit notifications, but I’m now migrating PTT functionality to the PushToTalk Framework while keeping CallKit for standard VoIP calls. I’m facing a few challenges that I’d like help with: Handling Incoming Push-To-Talk Calls When the App Is Closed and the Device Is Locked I considered continuing to use PushKit notifications to alert users via CallKit and using CallKit until the user brings the app into the foreground, at which point I’d switch to the PushToTalk Framework. While this could technically work, the user experience is not ideal. Are there any recommended approaches for handling PTT calls in this state? Handling Incoming PTT Calls When the App Is in the Background According to Apple documentation, I cannot join a PTT session unless my app is in the foreground. However, in practical scenarios, we often receive incoming PTT calls while the app is in the background. What’s the best solution for this situation? It feels odd to show notifications or use CallKit until the app is foregrounded. Conflict Between Ongoing PushToTalk Call and Incoming Cellular Call Currently, if there’s an ongoing PushToTalk call using the PTT framework and a cellular call comes in, if I receive a PTT transmission and call requestBeginTransmission, the cellular call is ended. I can handle this within my app, but is this expected behavior? Is this the intended conflict management for concurrent PTT and cellular calls? Lastly, a broader question: when will the unrestricted-voip entitlement stop working? I’m contemplating using this entitlement to handle incoming PTT calls without CallKit, but I’m concerned about its longevity. Some apps have been using it for messaging and other features for over four years, and it’s still functional for them. Any guidance or insights on these points would be greatly appreciated! Thanks in advance!

Hello. We are using Twilio Video SDK and CallKit to report an incoming invite to join a video room. We noticed that on iOS 18 beta when accepting the incoming call invite using Bluetooth headphones while the application is in the foreground, the CallKit screen for a moment enters the foreground before going into background. On iOS 17 when the call invite is accepted, the application remains in foreground and the CallKit screen is instantly sent to background. This is not reproducible when using Apple EarPods on iOS 18 with a Lightning connector. This seems like a minor change. But it would be nice to know if this is an intentional change or a possible issue.

Hello. We are using Twilio Video SDK and CallKit to report an incoming invite to join a video room. On iOS 18 trying to decline a call invite via headphones (long pressing the accept button) doesn't actually result in the call being declined. There seem to be different results depending on the device being used. When using Apple EarPods with Lightning connector or a Bluetooth JBL headset, the call is declined only on a second attempt. When using a Bluetooth Jabra BT2046 headset, the call gets accepted instead on the first decline attempt. This issue is not reproducible on iOS 17.

Hello. We are using Twilio Video SDK and CallKit to report an incoming invite to join a video room. On iOS 18 beta when the user receives the incoming call invite and taps the CallKit decline button, nothing happens. The incoming call UI is still visible. Only after tapping the decline button a second time the call invite is actually ended. The provider(CXProvider, perform: CXEndCallAction) method is called both times when tapping the decline button twice. Strangely enough, it is also called when tapping the accept button on iOS 18. This is working fine on iOS 17 and there haven't been any recent code changes in the application. Did anyone else encounter a similar issue with CallKit on iOS 18 beta ?

Hello, We are implementing an mVOIP service using CallKit. I have a question. When receiving a call with CallKit, the CXEndCallAction callback is received by the provider after one minute. We didn't request this separately on our end. Is this a policy from Apple? If so, is it possible to modify this behavior, and are there any related APIs or documentation? Thank you.

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

I can reproduce the bug that CallKit doesn't active audiosession after the outgoing call put on hold because of an incoming call. VoIP calling with CallKit Steps to reproduce: Download SpeakerBox example app from the link above and start it with XCode Start a new outgoing call Call your phone from other phone Hold and Accept the call After a few secs finish the call from the other phone The outgoing call will be still on hold Click on the call and click Toggle Hold The call won't be active again because the audiosession is activated. Logs: Received provider(_:didDeactivate:) Received provider(_:didDeactivate:) Received provider(_:didDeactivate:) Received provider(_:didDeactivate:) Received provider(_:didDeactivate:) Requested transaction successfully Starting audio Type: stdio AURemoteIO.cpp:1162 failed: 561017449 (enable 3, outf< 1 ch, 44100 Hz, Float32> inf< 1 ch, 44100 Hz, Float32>) Type: Error | Timestamp: 2024-08-15 12:20:29.949437+02:00 | Process: Speakerbox | Library: libEmbeddedSystemAUs.dylib | Subsystem: com.apple.coreaudio | Category: aurioc | TID: 0x19540d AVAEInternal.h:109 [AVAudioEngineGraph.mm:1344:Initialize: (err = PerformCommand(*outputNode, kAUInitialize, NULL, 0)): error 561017449 Type: Error | Timestamp: 2024-08-15 12:20:29.949619+02:00 | Process: Speakerbox | Library: AVFAudio | Subsystem: com.apple.avfaudio | Category: avae | TID: 0x19540d Couldn't start Apple Voice Processing IO: Error Domain=com.apple.coreaudio.avfaudio Code=561017449 "(null)" UserInfo={failed call=err = PerformCommand(*outputNode, kAUInitialize, NULL, 0)} Type: Notice | Timestamp: 2024-08-15 12:20:29.949730+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d Route change: Type: Notice | Timestamp: 2024-08-15 12:20:30.167498+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d ReasonUnknown Type: Notice | Timestamp: 2024-08-15 12:20:30.167549+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d Previous route: Type: Notice | Timestamp: 2024-08-15 12:20:30.167568+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d <AVAudioSessionRouteDescription: 0x302c00bc0, inputs = ( "<AVAudioSessionPortDescription: 0x302c01330, type = MicrophoneBuiltIn; name = iPhone Mikrofon; UID = Built-In Microphone; selectedDataSource = (null)>" ); outputs = ( "<AVAudioSessionPortDescription: 0x302c004d0, type = Receiver; name = Vev\U0151; UID = Built-In Receiver; selectedDataSource = (null)>" )> Type: Notice | Timestamp: 2024-08-15 12:20:30.167626+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d

With the Live Caller ID example server, the caller lookup dataset is defined in an input.txtpd and processed by running a ConstructDatabase command which creates a block.binpb and an identity.binpb file. In other words, a static input file is being processed into static block and identity files. However, in the real world, the data content for identified and blocked numbers is something which is in a constant state of flux and evolution, as new numbers becoming available, old ones become stale, numbers which were initially considered safe change into being considered malicious etc. etc. Is the example server just that, merely an example using fixed datasets, and an actual production server is able to use live every changing data to formulate its response back to the iPhone OS query? Here's a concrete use case - suppose it's a requirement to permit US nanp numbers but to block anything else. The total number of non US nanp numbers is so large and ever changing that it would be unfeasible to attempt to capture them in an input.txtpd file and then process that, and then to re-capture and re-process it endlessly. Instead what would be required is the ability for the Live Caller ID server to evaluate at query time, using a regular expressions for example, if a number is nanp or not. Is this possible?

The documentation for adding images for Live Caller ID specify that they should be in .heic format and be less than 64KB. However the majority of the time they just don't display. Mostly they would with iOS 18 beta 4, but with beta 5, 90% of the time they don't display. Seems there's some other factor at play, such as pixel size of width/height, or resolution density?

Hello Apps and their extensions are able to communicate with each other by reading/writing data stored in a shared group location. However this isn't the case with the the Live Caller ID Extension - if data is written to group defaults for example (as opposed to standard defaults) by the app, then that data isn't readable by the Caller ID extension. This has the consequence that its not possible for a user to dynamically switch which data set the extension connects to. Consider the use case where the Live Caller ID Server has one data set where callers are not blocked, and another where they are blocked, then the caller id extension can route different requests to different datasets based on the "user tier". However as the extension can't read data from the shared group then the app can't communicate user preferences to the extension, therefore the switching isn't possible. Is this by design or due to the immaturity of the feature? If its by design, then it means the use case outlined above isn't possible, and thus greatly reduces the possible functionality of the Live Caller Id feature. (It would be possible for the app to install multiple extensions, each of which connects to a different data set by specifying a different user tier, but the user having to flip these one and off within the Settings app is a dreadful user experience).

I am developing an app in Flutter and I need to implement iOS CallKit functionality to identify and store caller data within the app. I would like to know how to integrate CallKit into a Flutter application and what steps I need to follow to manage caller identification and data storage. I have done some research and understand that I will need to write native Swift code to handle CallKit, but I am not sure how to properly integrate it with Flutter and manage communication between the native code and Dart code. My specific questions are: How do I set up CallKit in a Flutter project? What permissions and configurations do I need in the Info.plist file? How can I receive and handle incoming call data using CallKit? How can I communicate this data to the Dart code in Flutter to store and display it in the user interface? Any code examples, tutorials, or advice would be greatly appreciated. Thanks in advance for your help. I have tried several approaches to implement iOS CallKit in my Flutter app: Online Forums: I have researched various online forums and discussion boards where developers share their experiences and solutions for integrating CallKit with Flutter. Unfortunately, I have not found a complete solution that addresses my specific requirements. Pub.dev Packages: I have explored different packages available on pub.dev, such as flutter_callkit_incoming and flutter_callkit, and tried to implement them in my project. However, I have encountered issues with proper integration and communication between the native Swift code and Flutter. GitHub Repositories: I have also looked at several GitHub repositories where developers have shared their implementations of CallKit in Flutter. While these repositories provided some insights, I was unable to achieve the desired functionality on my physical device. Despite following the instructions and examples from these sources, I have not been able to get CallKit to work correctly on my physical device. I am expecting to be able to identify the caller, and store the caller data within my Flutter app.