The broad issue you're describing here is "my app works perfectly when I launch it myself, but doesn't work right when the system launches my app into the background". To clarify our exact situation: When our app is suspended in the background, PushToTalk works perfectly When the user kills our app, the PushToTalk UI indicator (blue circle) remains visible, but the functionality fails (can't record or play audio) Anyway, thank you for your detailed explanation. I believe our understanding is now aligned with yours: I understand that an active PTT app should still be able to use PushToTalk functionality even after being force-quit, as the system should relaunch it when needed. The presence of the blue UI indicator confirms the channel is still active at the system level. We're still uncertain about the specific issue in our implementation. But we are examinating if any bugs. We've submitted a DTS request to get more specific guidance and hopefully access to the sample project you mentioned that demonstrates the correct implementation. We look forward to resolving this issue. Thank you for your assistance.

Hi Kevin, Thank you for your response. While your explanation about entitlements and audio session management is helpful, our specific issue remains unaddressed. To clarify our exact scenario: We're using the official PushToTalk framework as recommended When our app is running normally (background or foreground), the system UI (blue circle in status bar/Dynamic Island) works perfectly When a user force quits our app, the blue PushToTalk UI indicator remains visible in the system UI However, when users press and hold this system UI control to talk, they cannot record or play audio This behavior seems to contradict the statement in your previous forum responses that "The PushToTalk framework will deliver push notification payloads to your app as long as the user remains joined to the channel, even if your app terminates." Since the blue UI indicator remains visible after force quit (suggesting the channel is still active), shouldn't the system UI's press-and-hold functionality continue to work? Or is there something specific about the recording functionality through system UI that's expected to stop working after force quit? We're not attempting to directly activate audio sessions ourselves when using the system UI controls. We rely entirely on the PTChannelManager framework to handle this when users interact with the blue circle UI. Thank you for any clarification on this specific use case.

Hi Kevin and everyone, Thanks for the detailed clarifications in this thread, especially regarding the deprecation timeline and intended migration path away from the com.apple.developer.pushkit.unrestricted-voip (disabled since iOS 15 SDK) and the com.apple.developer.pushkit.unrestricted-voip.ptt (deprecated, still functional on iOS 18 but slated for future disabling, urging migration to PushToTalk). The guidance clearly states that all PTT developers should transition to the PushToTalk framework and that PushKit should only be used for incoming call notifications requiring CallKit reporting. However, this official stance creates significant confusion when observing certain apps in the wild. Specifically, the app Ten Ten (Bundle ID: com.tenten.app), which appears to have launched relatively recently (likely 2023/2024), seems to operate directly counter to this guidance. Based on inspection of its entitlements, Ten Ten explicitly includes both: <key>com.apple.developer.pushkit.unrestricted-voip</key> <true /> <key>com.apple.developer.pushkit.unrestricted-voip.ptt</key> <true /> This aligns with its observed behavior: instant audio delivery even on locked screens, without the standard blue PushToTalk status bar indicator that would typically appear if a PTChannelManager session was active. This strongly implies reliance on these special entitlements rather than the prescribed PushToTalk framework methods discussed here. This raises critical questions for developers trying to follow Apple's stated direction: Given the deprecation status and the push towards the PushToTalk framework, how was a relatively new application like Ten Ten seemingly able to obtain approval for both the .ptt and the supposedly long-disabled general unrestricted-voip entitlement? Is there an exception process or specific criteria under which these deprecated entitlements are still being granted, which hasn't been communicated broadly? How should developers reconcile the strong official guidance provided here with the existence and apparent successful operation of apps that seem to be using these "off-limits" entitlements? Understanding this discrepancy is crucial for the developer community to build compliant and future-proof applications based on a clear and consistently applied set of rules. Any further insight into how this situation with Ten Ten is possible would be immensely helpful. tenten.entitlements Thanks.

Thank you for your previous response and clarification regarding the PushToTalk framework and the status of the unrestricted-voip entitlements. Based on the official guidance you and others have provided, our understanding is: com.apple.developer.pushkit.unrestricted-voip has been functionally disabled since the iOS 15 SDK. com.apple.developer.pushkit.unrestricted-voip.ptt is deprecated, no longer granted through standard requests, and developers are strongly urged to migrate to the PushToTalk framework. Its continued functionality is temporary and tied to older SDKs. Using the PushToTalk framework correctly involves the PTChannelManager and typically results in a system UI indicator (like the blue status bar item) when a session is active. However, we're observing behavior in a specific, relatively popular app – Ten Ten (Bundle ID: com.tenten.app) – that seems inconsistent with this guidance, causing significant confusion for developers trying to follow the rules. Analysis of the Ten Ten app's entitlements reveals the presence of both special VoIP entitlements: <key>com.apple.developer.pushkit.unrestricted-voip</key> <true /> <key>com.apple.developer.pushkit.unrestricted-voip.ptt</key> <true /> Furthermore, the app successfully delivers its core "walkie-talkie" audio functionality instantly, even when the receiving device is locked, without displaying the standard PushToTalk system UI indicator in the status bar. This behavior strongly suggests it's leveraging these specific entitlements rather than the standard PushToTalk framework flow managed by PTChannelManager. Given that Ten Ten appears to have launched publicly around 2023/2024 (well after the general unrestricted-voip was disabled and during the period the .ptt variant was being actively deprecated): How was it possible for this app to obtain both of these highly restricted entitlements, particularly the .ptt variant, at a time when Apple was guiding developers away from them and towards the PushToTalk framework? How are these entitlements, especially the supposedly disabled general unrestricted-voip, seemingly still functioning within this specific app, allowing it to bypass standard PushToTalk UI conventions? Is there an uncommunicated policy, an exception process, or a specific partnership arrangement that allows certain applications to receive and utilize these deprecated/restricted entitlements, while others are directed strictly to the standard frameworks? We are genuinely trying to understand the landscape and build compliant, reliable apps using the recommended frameworks. The apparent discrepancy exemplified by Ten Ten makes it difficult to reconcile the official guidance with real-world observations. Any clarification you could provide on how such a situation is possible under current policies would be greatly appreciated by the developer community. Thank you. tenten.entitlements