Hi team, I am developing VOIP feature using PushKit and CallKit but CallKit is not show when app in background or terminate state, now in foreground state I can call reportNewIncomingCall from pushRegistry-didReceiveIncomingPushWith and it's work as expected but the problem is in background or terminate state it's not my setup: PushKit is configured In Signing & Capabilities I add background modes (Remote notifications and Voice over IP) In info.plist I add <key>UIBackgroundModes</key> <array> <string>voip</string> I'm not sure should I create new VOIP Certificate but now I can receive message notification normally. Any help or suggestions would be greatly appreciated Thank you

We are currently developing a VoIP application that supports Local Push extention. I would like to ask for your advice on how the extension works when the iPhone goes into sleep mode. Our App are using GCD (Grand Central Dispatch) to perform periodic processing within the extension, creating a cycle by it. [sample of an our source] class LocalPushProvider: NEAppPushProvider { let activeQueue: DispatchQueue = DispatchQueue(label: "com.myapp.LocalPushProvider.ActiveQueue", autoreleaseFrequency: .workItem) var activeSchecule: Cancellable? override func start(completionHandler: @escaping (Error?) -&gt; Void) { : self.activeSchecule = self.activeQueue.schedule( after: .init(.now() + .seconds(10)), // start schedule after 10sec interval: .seconds(10) // interval 10sec ) { self.activeTimerProc() } completionHandler(nil) } } However In this App that we are confirming that when the iPhone goes into sleep mode, self.activeTimerProc() is not called at 10-second intervals, but is significantly delayed (approximately 30 to 180 seconds). What factors could be causing the timer processing using GCD not to be executed at the specified interval when the iPhone is in sleep mode? Also, please let us know if there are any implementation errors or points to note. I apologize for bothering you during your busy schedule, but I would appreciate your response.

Currently working on a dating app which needs voip for audio and video calls for ios. the voip notifications only comes to the app in active and inactive mode but doesnt wake the device in background or terminated mode. After debugging i noticed that com.apple.developer.voip entitlement wasnt included which i later added, trying to create a build i get the eas error that the entitlement wasnt added to the identifier capabilities. My issue now is that i can't seem to find the voip capability to check in the identifiers capabilities list for the bundle id.d

Hello everyone, Our team is currently developing a PTT (Push-to-Talk) application using the officially recommended PushToTalk framework. During development, we've encountered a point of confusion regarding the application's behavior after being force-quit by the user. Based on our understanding of the PushToTalk framework documentation (https://developer.apple.com/documentation/pushtotalk/creating-a-push-to-talk-app/) and the PTChannelManager session restoration mechanism, when a user manually kills the app from the background (App Switcher), the current PTT session (the system session managed by PTChannelManager) should terminate. Subsequent pushtotalk type pushes sent via APNS, without an active session, appear to be silently discarded by the system and cannot wake the app for processing (similar to what Kevin Elliott DTS mentioned in https://developer.apple.com/forums/thread/760506 Point D). This seems to prevent reliable PTT message reception in our app after a user force quits. However, we've observed that some popular PTT applications on the market (e.g., TenTen) appear to successfully receive and play PTT voice messages from friends even after the user has performed a force-quit action. This behavior seems inconsistent with our test results and understanding based on the standard framework, posing a challenge for us in providing similar reliability using standard methods. This naturally leads us to wonder how this capability is achieved. We've reviewed developer forums and are aware of the historical existence of a PTT-specific com.apple.developer.pushkit.unrestricted-voip entitlement, which allowed PushKit usage for PTT without CallKit binding. While Apple DTS engineers have repeatedly stated this entitlement is being deprecated and urged migration to the PushToTalk framework (e.g., https://developer.apple.com/forums/thread/763289), we are curious if the observed "wake-after-force-quit" capability might be related to some apps potentially still utilizing this outgoing special entitlement. Alternatively, is there perhaps a mechanism within the standard PushToTalk framework that allows wake-up after force quit that we haven't fully grasped? Therefore, we'd like to ask fellow developers for clarification and discussion: When using the standard PushToTalk framework, have others confirmed that the app indeed cannot be woken up by pushtotalk pushes after being force-quit by the user? Is this the expected behavior? Has anyone successfully achieved a TenTen-like experience (reliable PTT reception after force quit) using only the standard PushToTalk framework? If so, could you share key implementation insights or areas to focus on? (e.g., Is it related to specific usage patterns of the restorationDelegate?) How do you view this potential discrepancy between standard framework capabilities and the behavior exhibited by some apps? What considerations does this bring to development planning and user experience design (especially when users might have expectations set by the "always-on" behavior of other apps)? Are there any best practices or specific techniques when using PTChannelManager session management and restoration that maximize PTT message reliability (especially after the app is terminated by the system in the background), while still adhering to the framework's design principles (like user awareness of the session via UI)? [For instance, another developer raised challenges related to PTT framework restrictions here: https://developer.apple.com/forums/thread/773981] We hope this discussion can help clarify our understanding of the framework and gather community best practices for building reliable PTT functionality while adhering to Apple's guidelines. Thanks for any insights or shared experiences!

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