PushToTalk Framework Behavior After Force Quit and Challenges in Achieving Reliable PTT Functionality

Thanks for your question. The PushToTalk framework has been designed to ensure reliable messaging and does allow your app to continue receiving push notifications even after your app is terminated or the device is rebooted.

The first steps in the PushToTalk workflow are to initialize your PTChannelManager by calling channelManager(delegate:restorationDelegate:completionHandler:). You should initialize the channel manager as soon as possible during startup to ensure the framework can restore an existing channel if needed and deliver push notifications to the app. Once you have initialized the PTChannelManager, you should join the channel by calling requestJoinChannel(channelUUID:descriptor:). This must be called when your app is in the foreground.

After joining the channel, your app will be able to receive PushToTalk push notifications for incoming audio messages. Whenever the system receives an incoming message, it will launch your app in the background and deliver the push notification payload to your incomingPushResult(channelManager:channelUUID:pushPayload:) method, which allows you to set the active speaker. As long as the user remains joined to the PushToTalk channel, you will continue to see the PushToTalk icon in the system status bar or Dynamic Island, and your app will continue to receive incoming push notifications, even if the user or the system terminates your app.

See responses to your questions below:

1. 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?

See notes above. 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.

2.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?)

Your app will receive PushToTalk notifications even after force quitting. Follow the steps above. It is especially important to initialize PTChannelManager as soon as possible during app start-up to deliver notification payloads to your delegate.

1. 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)?

All apps implementing a push-to-talk workflow should adopt the PushToTalk framework. The legacy PTT entitlement will be deprecated and stop functioning in a future iOS release. The PushToTalk framework offers greater reliability by maintaining an ongoing PushToTalk channel that persists across app terminations and system reboots.

1. 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)?

To reduce the time needed to start playing incoming PushToTalk messages, streamline your app’s startup. Ensure quick app launches and initialize your PTChannelManager as early as possible. Also, makes sure your app responds quickly to channel restoration requests to avoid delays in restoration and push notification delivery.

I hope this information clears up your questions about the PushToTalk framework!

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:

1. com.apple.developer.pushkit.unrestricted-voip has been functionally disabled since the iOS 15 SDK.

2. 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.

3. 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):

1. 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?

2. 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?

3. 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.

    
        application-identifier
        4WVUJ4FZM8.com.tenten.app
        aps-environment
        production
        com.apple.developer.applesignin
        
            Default
        
        com.apple.developer.associated-domains
        *
        com.apple.developer.networking.multipath
        
        com.apple.developer.pushkit.unrestricted-voip
        
        com.apple.developer.pushkit.unrestricted-voip.ptt
        
        com.apple.developer.siri
        
        com.apple.developer.team-identifier
        4WVUJ4FZM8
        com.apple.developer.usernotifications.communication
        
        com.apple.developer.usernotifications.time-sensitive
        
        com.apple.security.application-groups
        
            group.com.tenten.app
        
        keychain-access-groups
        
            4WVUJ4FZM8.com.tenten.app
            com.apple.token
        
    

1. com.apple.developer.pushkit.unrestricted-voip has been functionally disabled since the iOS 15 SDK.

Yes, that's correct. Many apps does still include to either support older systems or because they simply have not removed it, but it has no effect whatsoever.

1. 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.

Also correct, though "strongly" understates the warning level. It's only visible in development builds, but the system actually posts periodic alert dialogs warning that this entitlement will be disabled "soon" when an app relies on this entitlement. The behavior is not subtle and exists to ensure that every PTT developer knows that this entitlement should no longer be relied on.

1. 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.

Yes, that's correct.

Reordering things a bit, let me actually start here:

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.

I understand that there is sometimes a feeling among outside developers that some developers are given "special" treatment. While I can't say that this is true for everything Apple does, I can say that this is NOT true of the PTT entitlement. This entitlement was only ever granted to Push To Talk apps and the we stopped granting the entitlement shortly after the PushToTalk framework shipped in iOS 16.

I'm not going to comment on our interactions with any specific developer or app, but I will try to answer your questions in general terms.

1. 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?

Your assumption here is that entitlement grants happens at or near the time an app ships, but that assumption is generally incorrect. Most developer request the entitlements they need when they begin development, particularly for a situation like this where the entitlement is essential to the apps basic functionality. PTT apps in particular tend to be complex apps to implement and often take several years to develop. That means a PTT app that shipped in 2022 (iOS 16) would have started development in 2020 (or earlier), which is when they would have been granted the entitlement.

1. 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?

As I described above, the PTT entitlement does still function in iOS 18. We have provided PTT apps with a generous time frame to transition to the PushToTalk framework and those apps are now being actively warned that the should not continue to rely on it.

1. 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?

No, nothing like this exists for the PTT entitlement.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware