The app must be updated to use the new Push to Talk framework pop up display even after adding PTT framework

Hello All, I am getting following popup for our application,

I have implemented PTT Push To Talk framework by following https://developer.apple.com/documentation/pushtotalk/creating-a-push-to-talk-app

We are using following VoIP entitlements, Our app support from iOS 12 i) com.apple.developer.pushkit.unrestricted-voip ii) com.apple.developer.pushkit.unrestricted-voip.ptt

We have updated app with new Push To Talk framework and it's working fine. Our app's minimum deployment target is iOS-12.0 , So app will also work without using PTT framework for older iOS.

Question,

  1. Why popup display even after new Push To Talk framework implementation?

  2. what should I do to remove this popup from showing? Should I do any other setting to complete this framework?

Thanks.

Answered by DTS Engineer in 797372022

When app is not active or in suspended state, voip used to wake app. Our application is walkie talkie type app, so we can't report to call kit for incoming Push to talk audio, becuse of it we are using com.apple.developer.pushkit.unrestricted-voip and related certificate.

Yep, I know. The person at DTS who helped you get that entitlement was me.

As you mentioned we should stop using PushKit push in didReceiveIncomingPushWithPayload, then how will app wake up when user receive PTT audio, or new user request to join in call.

So the answer here is that this method:

As for below function, it's only triggered if app is in call. nonnull PTPushResult *)incomingPushResultForChannelManager:(nonnull PTChannelManager *)channelManager channelUUID:(nonnull NSUUID *)channelUUID pushPayload:(nonnull NSDictionary<NSString *,id> *)pushPayload

...is how all of your PTT "receives" should be handled. The expected usage "flow" of the PTT framework looks like this:

  1. The user launch your app does and starts your "PTT session".

  2. Your app checks in with your server, PTT messages start, etc.

  3. Your app receives ALL incoming PTT Audio pushes through "incomingPushResultForChannelManager".

  4. When the user no longer wants to recieve PTT messages/data, then end their PTT session (either through your app or through the system UI).

Making this clear, one of the design goals of the PTT framework was to make sure it was visible to the user that a PTT app was active. This is a change from how things "used" to work, but it's something you need to adapt to. The expectation is that your app should NOT "work" as a PTT app unless it is the active PTT app, which "controls" the system UI.

Filling out some details of that architecture:

A) With the benefit of hindsight, the PTT framework should NOT have used the term "channel" in it's API. We used that term because it's common to PTT apps, but using that term has end up creating unnecessary confusion because we're using the same word for two unrelated things. PTChannelManager's job is simply to manage your connection with the system, NOT whatever channel concept your app might use. I try to use the term "session", meaning "you've used PTChannelManager.requestJoinChannel to become active and are currently the active PTT app" to try and avoid this confusion.

B) Your app can and should manage it's own "channel's" (or whatever you call them) however it wants. For example, your app's design may mean that you have dozen's (or hundreds) of "Channels" (or even "none") and that the user may be in 1, 100, or none. Those design choices have have nothing to do with PTChannelManager. You only have one connection to the system, so you'll only ever have "one". FYI, PTChannelManager is actually a singleton so you should actually ONLY have one, which you you initialize once at startup and use forever, even if your app doesn't have an active PTT session.

C) The system currently only supports having one PTT app active at a time. While this might seem problematic, our own experience is that real world PTT usage is targeted/restricted enough that this isn't a problem.

D) One detail that's a bit subtle here is that the PTT push token will actually "work" even if you don't have an active PTT session. That is, when you send a PPT push to a device, either:

  1. If you have an active PTT session, then your app will recieve the push through "incomingPushResult...".

  2. If you don't, then the push will be silently discarded.

Most PTT apps manage whether or not PTT pushes are sent by having the user check in with their server, however, that behavior above ("D") means that you don't actually have to work that way if you don't want to. A "broadcast" oriented app can simply send a push to all (relevant) users and let the local device control who actually heard the message(s).

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Why popup display even after new Push To Talk framework implementation?

That dialog is triggered if:

  • Your app has the Unrestricted PushKit (PTT) entitlement. If you didn't have this entitlement, then your app would have simply crashed.

  • It received a PushKit push in didReceiveIncomingPushWithPayload.

  • It did NOT report a call to CallKit as the modern API contract requires.

That dialog was added to warn you that you are still relying on the functionality the "Unrestricted PushKit (PTT)" entitlement provides. That functionality was deprecated by the PTT framework and will eventually stop working, at which point the situation above will cause you app to crash.

Two other small notes on this:

  1. There is throttling logic in place so that you don't actually see it for every single push you fail to report. It's intended to be presented once every ~24 hours, but you may see if more often when your actively modifying your build during development.

  2. I believe that dialog is currently only be occurring in development builds, not your App Store release. That may change in the future, but the goal at the moment is simply to warn you that you're relying on the deprecated PushKit architecture.

We have updated app with new Push To Talk framework and it's working fine. Our app's minimum deployment target is iOS-12.0 , So app will also work without using PTT framework for older iOS.

Note that just having the entitlement isn't an issue, it's specifically that you failed to report call as required.

what should I do to remove this popup from showing? Should I do any other setting to complete this framework?

You need to stop using PushKit for anything other than voip calls and/or you need to report a voip call for every voip push.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware.

When app is not active or in suspended state, voip used to wake app. Our application is walkie talkie type app, so we can't report to call kit for incoming Push to talk audio, becuse of it we are using com.apple.developer.pushkit.unrestricted-voip and related certificate.

As you mentioned we should stop using PushKit push in didReceiveIncomingPushWithPayload, then how will app wake up when user receive PTT audio, or new user request to join in call.

As for below function, it's only triggered if app is in call. nonnull PTPushResult

*)incomingPushResultForChannelManager:(nonnull PTChannelManager *)channelManager channelUUID:(nonnull NSUUID *)channelUUID pushPayload:(nonnull NSDictionary<NSString *,id> *)pushPayload

When app is not active or in suspended state, voip used to wake app. Our application is walkie talkie type app, so we can't report to call kit for incoming Push to talk audio, becuse of it we are using com.apple.developer.pushkit.unrestricted-voip and related certificate.

Yep, I know. The person at DTS who helped you get that entitlement was me.

As you mentioned we should stop using PushKit push in didReceiveIncomingPushWithPayload, then how will app wake up when user receive PTT audio, or new user request to join in call.

So the answer here is that this method:

As for below function, it's only triggered if app is in call. nonnull PTPushResult *)incomingPushResultForChannelManager:(nonnull PTChannelManager *)channelManager channelUUID:(nonnull NSUUID *)channelUUID pushPayload:(nonnull NSDictionary<NSString *,id> *)pushPayload

...is how all of your PTT "receives" should be handled. The expected usage "flow" of the PTT framework looks like this:

  1. The user launch your app does and starts your "PTT session".

  2. Your app checks in with your server, PTT messages start, etc.

  3. Your app receives ALL incoming PTT Audio pushes through "incomingPushResultForChannelManager".

  4. When the user no longer wants to recieve PTT messages/data, then end their PTT session (either through your app or through the system UI).

Making this clear, one of the design goals of the PTT framework was to make sure it was visible to the user that a PTT app was active. This is a change from how things "used" to work, but it's something you need to adapt to. The expectation is that your app should NOT "work" as a PTT app unless it is the active PTT app, which "controls" the system UI.

Filling out some details of that architecture:

A) With the benefit of hindsight, the PTT framework should NOT have used the term "channel" in it's API. We used that term because it's common to PTT apps, but using that term has end up creating unnecessary confusion because we're using the same word for two unrelated things. PTChannelManager's job is simply to manage your connection with the system, NOT whatever channel concept your app might use. I try to use the term "session", meaning "you've used PTChannelManager.requestJoinChannel to become active and are currently the active PTT app" to try and avoid this confusion.

B) Your app can and should manage it's own "channel's" (or whatever you call them) however it wants. For example, your app's design may mean that you have dozen's (or hundreds) of "Channels" (or even "none") and that the user may be in 1, 100, or none. Those design choices have have nothing to do with PTChannelManager. You only have one connection to the system, so you'll only ever have "one". FYI, PTChannelManager is actually a singleton so you should actually ONLY have one, which you you initialize once at startup and use forever, even if your app doesn't have an active PTT session.

C) The system currently only supports having one PTT app active at a time. While this might seem problematic, our own experience is that real world PTT usage is targeted/restricted enough that this isn't a problem.

D) One detail that's a bit subtle here is that the PTT push token will actually "work" even if you don't have an active PTT session. That is, when you send a PPT push to a device, either:

  1. If you have an active PTT session, then your app will recieve the push through "incomingPushResult...".

  2. If you don't, then the push will be silently discarded.

Most PTT apps manage whether or not PTT pushes are sent by having the user check in with their server, however, that behavior above ("D") means that you don't actually have to work that way if you don't want to. A "broadcast" oriented app can simply send a push to all (relevant) users and let the local device control who actually heard the message(s).

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I have some doubt, can you please help me to clarify it?

1. Is this popup will only show on development and testflight build and not in app store released build?

So for now we can ignore it.

2. Are we using deprecate pushkit Or PushKit will deprecate in new version of iOS ?

I have some doubt, can you please help me to clarify it?

  1. Is this popup will only show on development and testflight build and not in app store released build?

So for now we can ignore it.

Depends on what you mean by ignore. The warning exists to make sure you're aware that you're doing something wrong and that your app WILL start crashing (at some point) because of it. You need to stop using PushKit for this. However, currently the dialog is not something your users will see, nor is the system currently terminating your app.

  1. Are we using deprecate pushkit

PushKit itself is not deprecated. What's deprecated is the "com.apple.developer.pushkit.unrestricted-voip.ptt" entitlement. The PTT framework has replaced that entitlement and your app needs to fully adopt it, which also means that you should NOT be sending PTT related pushes through voip pushes (which are then handled by PushKit). Your app should ONLY be using voip pushes for incoming call notifications, which means you should be reporting a call to CallKit for EVERY voip push PushKit receives.

Or PushKit will deprecate in new version of iOS ?

The "com.apple.developer.pushkit.unrestricted-voip.ptt" entitlement continues to function in the beta seed, so I expect it to continue function when iOS 18 is released.

Note that, I'd expect the ppt entitlement variant to be disabled using exactly the same process the base entitlement used (which has been disabled since ~iOS 14). The system will check the SDK version used to build your app and disabled the entitlement in apps that are using that SDK version. This allows shipping/existing/older app versions to continue working without any issue, while also ensuring that you complete the transition to the PTT framework.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

The app must be updated to use the new Push to Talk framework pop up display even after adding PTT framework
 
 
Q