iOS 10 and kCFStreamNetworkServiceTypeVoIP

I work on a push-to-talk application that utilizes the kCFStreamNetworkServiceTypeVoIP flag to function in the background.



In iOS 9 kCFStreamNetworkServiceTypeVoIP was deprecated but it has continued to be an effective way of allowing for real-time audio. Will apps that use this flag require special approval in iOS 10? Have the system rules regarding backgrounded apps with this flag changed at all?


Into the future, what would you recommend developers use for instantaneous background audio? I fear that PushKit may be too slow for push to talk.

Replies

To start, I want to clarify one point. You wrote:

In iOS 9 kCFStreamNetworkServiceTypeVoIP was deprecated but it has continued to be an effective way of allowing for real-time audio.

You’re using the phrase “real-time audio” is an unusual way here. Most folks who talk about real-time audio are referring to the streaming audio with latency concerns that reach down into the millisecond range.

kCFStreamNetworkServiceTypeVoIP
does not help with that in any way. Rather, folks with real-time audio needs will typically use
kCFStreamNetworkServiceTypeVoice
, which has not been deprecated.

With regards the requirements of your push-to-talk app, you wrote:

Will apps that use this flag require special approval in iOS 10?

They already require special approval, in that you have to be a VoIP app to use them (you have to add

voip
in
UIBackgroundModes
).

Have the system rules regarding backgrounded apps with this flag changed at all?

We’ve nothing specific to announce at this time. However, I should stress that we’re actively encouraging VoIP developers to move from the legacy VoIP architecture to the new PushKit-based VoIP architecture. This has a number of consequences:

  • We’re not going to make any feature-level improvements to the legacy VoIP architecture.

  • The legacy VoIP architecture, which was never 100% reliable at the best of times, is unlikely to get more reliable. Moreover, as more apps make the switch it’s not hard to imagine the reliability decreasing.

  • At some point we may remove the legacy VoIP architecture although, as I said earlier, we’ve no announced plans on that front.

Into the future, what would you recommend developers use for instantaneous background audio? I fear that PushKit may be too slow for push to talk.

Have you tried PushKit? My experience is that it’s pretty darned responsive.

At this point my recommendation is that you experiment with PushKit. If it’s not responsive enough to meet your needs, you should file a bug explaining your unique requirements in this space.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I have compiled our iPhone VoIP App under XCode8 Beta and tested on device running iOS10Beta..

From what I see with this kCFStreamNetworkServiceTypeVoIP is NOT supported anymore nor is voip UIBackgroundModes.


I know that these are deprecated in favour of Pushkit for some time. However we had hoped for more time before they would be actually be removed. It is a major change to migrate to use Pushkit for VoIP Applications.


Is there anyway to workaround this?


I would hope that the kCFStreamNetworkServiceTypeVoIP and voip UIBackgroundMode be reintroduced before XCode8 / iOS10 are released to allow more time to migrate to Pushkit


Thanks

PushKit has been availble for two major releases (iOS 8 and iOS 9). Deprecating something after 2 full years of having a demonstrably better replacement is not uncommon, and is a fairly large amount of time to allow for migration.

Thanks for the reply...Unfortunatley the migration to pushkit involves very significant changes to the actual VoIP infrastructure on the server end. It's not just a change for us iOS App developers. The main work involved is a a quite "radical" change to the way in which the VoIP server communicates with the VoIP App.


Within a small company we have to make choices about what to focus on and where to deploy our limited resources. We focused our development on adding features to improve the usefulness of our Apps hoping that the current background VoIP modes would also continue to be supported.


I do accept that battery life will be improved without constant traffic on a VoIP socket but I think that it should be up to the user NOT to use an App if they are unhappy with it's affect on battery. Again I would ask that kCFStreamNetworkServiceTypeVoIP and voip UIBackgroundMode be reintroduced before XCode8 / iOS10 are released to allow more time to migrate to Pushkit.

After upgrading to iOS10, we are facing problems in receiving background incoming calls at VoIP applications. As PushKit requires internet and our environment works in close network, with no internet connection.


In iOS10, is there any way to receive incoming calls at VoIP clients in background mode, when there is no internet available between PBX server and VoIP clients?

The answer to this direct question:

In iOS 10, is there any way to receive incoming calls at VoIP clients in background mode, when there is no internet available between PBX server and VoIP clients?

is “Yes, by building your app with Xcode 7.” There are obvious downsides to this:

  • You have to build on 10.11, because Xcode 7 is not supported on 10.12.

  • By building with an older SDK, you cut yourself off from new features, most notably CallKit.

  • You are using a technology that’s has no long-term future.

I strongly recommend that you find a way to make PushKit work in your target environments. For example, push notifications use a well-known port so you could configure your network to be generally closed but allow those outgoing connections.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Dear eskimo


Your feedback is a bit difficult to swallow. Believe it or not, but there are networks that the internet and Apple servers do not reach. Some networks are not connected to the internet either by choice or because of limitations. While I do understand that this does not account for 99% of voip application users, it does make it difficult for small companies to penetrate that 1% niche market.


The other problem is not quite the 1% market, but I would guess more the 25%-30% market that does not have access to the backbone infrastructure or the investment capital to upgrade existing server infrastructure to support APNS. To put this change in perspective, we have other clients that still use PSTN fax. I am aware of a not so famous Steve Jobs quote "Death will solve this" when talking about users that prefer writing with a stylus rather than using a finger to type, but I do think this move is a bit premature.


Is the only option now to service these two markets by using XCode 7 to build? Are the people at Apple at least talking about how to resolve these two use cases?


Hope to hear from the apple team soon.

Kind regards

Is the only option now to service these two markets by using XCode 7 to build?

Right now it’s the only option I can offer.

If you’d like iOS Engineering to consider your requirements while planning for the future, I recommend that you file a bug report describing those requirements.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks for the feedback. I want to add my voice to the issue discussed here.


The company I work for offers hardware to support a closed network VOIP solution but due to the limitations of PushKit and needing an internet connection, we are no longer able to support an iOS application at this time. Our only option is to create an in-house PNS which is unrealistic at this time.


I don't quite understand why the "Legacy VoIP Background Mode" had to be fully deprecated. Since PushKit does not cover all the same functionality the legacy code provided, it seems both have merit in existing beside each other. It would be of great help if we could have support for the legacy code returned or an alternative solution which works on closed networks. I hate to push customers to Android because Apple cannot provide the functionality needed for our product.