Hello Apple Developer Community, We're implementing the PushToTalk framework as recommended. According to Apple engineers in previous forum responses : the framework allows your app to continue receiving push notifications even after your app is terminated or the device is rebooted. Implementation: We've properly implemented: Early initialization of PTChannelManager via channelManager(delegate:restorationDelegate:completionHandler:) Channel joining with requestJoinChannel(channelUUID:descriptor:) when foregrounded All required delegate methods Issue After a user force quits our app, PushToTalk functionality works briefly but fails after some time (minutes to hours). The system logs show: AudioSessionServerImpCommon.mm:105 { "action":"cm_session_begin_interruption", "error":"translating CM session error", "session":{"ID":"0x72289","name":"getcha(2958)"}, "details":{ "calling_line":997, "error_code":-12988, "error_string":"Missing entitlement" } } We suspect that entitlement after force-quitting the app, there's a permission cache that temporarily allows functionality, but once this cache is cleared, the features stop working. Without this entitlement, both audio playback and recording fail, completely breaking the PTT functionality. Questions Which specific entitlement is missing according to this error? Is there a permission caching mechanism that expires after force quit? How can we ensure reliable PTT operation after force quit as stated in documentation? This behavior contradicts Apple's guidance that PushToTalk should work reliably after termination. Any insights would be greatly appreciated. Thank you!

Hello everyone, Our team is currently developing an iOS application requiring real-time audio communication and evaluating the most suitable frameworks. Options include CallKit, custom solutions using AVAudioEngine/Audio Units, and the PushToTalk framework. Regarding the PushToTalk framework, we have some questions about its core design and capabilities that we'd appreciate clarification on from the community or Apple engineers. Based on the PushToTalk framework documentation, its API design (e.g., methods like requestBeginTransmission, endTransmission which imply explicitly requesting transmission rights), and its system UI integration, it strongly appears oriented towards half-duplex communication scenarios, similar to traditional walkie-talkies where only one participant transmits audio at a time. Is this understanding accurate? Is the PushToTalk framework's design strictly limited to managing half-duplex audio interactions? Or, does the framework itself also provide built-in mechanisms or APIs to manage simultaneous, bi-directional (full-duplex) audio streaming between participants? To be clear, we are asking about the inherent capabilities of the PushToTalk framework itself. We understand it's possible to use PushToTalk for signaling and UI management, and separately implement the actual full-duplex audio stream using AVAudioEngine or other audio APIs. However, we want to confirm if the framework itself is designed to support or simplify full-duplex audio communication. Have other developers investigated the specific limitations or capabilities of the PushToTalk framework regarding audio transmission modes (half-duplex vs. full-duplex)? Are there any official documentation references or WWDC sessions that explicitly clarify the framework's support (or lack thereof) for full-duplex operation? If PushToTalk is indeed limited to half-duplex, what are the generally accepted best practices for apps requiring full-duplex calls – transitioning directly to CallKit (where applicable) or building custom audio processing pipelines? Clarifying this point is crucial for us to select the correct technology stack for our application. Any relevant insights, documentation pointers, or shared development experiences would be greatly appreciated. Thank you for your help!

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!