Slashdot Mirror
iOS 10 Quietly Deprecated A Crucial API For VoIP and Communication Apps (apple.com)
neutrino38 warns that iOS 10 includes a significant change "overlooked by the general public":
It deprecates an API that is crucial for VoIP and other instant messaging applications that enable keeping one socket active despite the fact that the application would run in the background. As a replacement, developers need to use PushKit: when an incoming call is to be forwarded to an iOS VoIP client, the VoIP infrastructure needs to:
- withold the call
- contact Apple push infrastructure using a proprietary protocol to wake up the client app remotely
- wait for the application to reconnect to the infrastructure and release the call when it is ready
This "I know better than you" approach is meant to further optimize battery life on iOS devices by avoiding the use of resources by apps running in background. It has also the positive effect of forcing developers to switch to a push model and remove all periodic pollings that ultimately use mobile data and clog the Internet. However, the decision to use an Apple infrastructure has many consequences for VoIP providers:
- the reliability of serving incoming calls is directly bound to Apple service
- Apple may revoke the PushKit certificate. It thus has life and death decision power over third-party communication infrastructures
- organizations wanting to setup IPBX and use iOS client have no option but to open access for the push services of Apple in their firewall
- It is not possible to have iOS VoIP or communication clients in network disconnected from the Internet - Pure standard SIP clients are now broken on iOS
The original submission argues that Apple is creating "the perfect walled garden," adding that "Ironically, the only VoIP 'app' that is not affected is the (future?) VoLTE client that will be added to iOS one day."
- withold the call
- contact Apple push infrastructure using a proprietary protocol to wake up the client app remotely
- wait for the application to reconnect to the infrastructure and release the call when it is ready
This "I know better than you" approach is meant to further optimize battery life on iOS devices by avoiding the use of resources by apps running in background. It has also the positive effect of forcing developers to switch to a push model and remove all periodic pollings that ultimately use mobile data and clog the Internet. However, the decision to use an Apple infrastructure has many consequences for VoIP providers:
- the reliability of serving incoming calls is directly bound to Apple service
- Apple may revoke the PushKit certificate. It thus has life and death decision power over third-party communication infrastructures
- organizations wanting to setup IPBX and use iOS client have no option but to open access for the push services of Apple in their firewall
- It is not possible to have iOS VoIP or communication clients in network disconnected from the Internet - Pure standard SIP clients are now broken on iOS
The original submission argues that Apple is creating "the perfect walled garden," adding that "Ironically, the only VoIP 'app' that is not affected is the (future?) VoLTE client that will be added to iOS one day."
I think the real joke here is that for a price of one of their phones you could instead have 2 kilos of pure silver.
It provides defense against lazy app writers. And it's courageous.
the carrier don't like what was disabled. Now you can't use an iPhone handset to bypass the carrier using VOIP
Apple deprecated the old VoIP interface one year ago. Absolutely obvious for anyone interested. But one year warning will obviously come as a surprise to some people.
VoIP required that your phone was turned on, your app was running, and regularly pulled requests. An absolute battery eater. The new feature allows your phone to be asleep, use no energy, and wake up immediately when a call arrives.
If rms weren't still alive, he'd be spinning in his grave in a display of told-you-so!
I'm looking at you facebook; what are the chances they were abusing the old API. It sounds like a right pain in the ass from a development point of view. Maybe though with this there could be a way from phone calls interrupting my skype calls. That would be a huge win.
Nah, including a battery powerful enough to give more than 30 minutes of battery life would mean making the phone 1mm thicker, and that is not the Apple way.
Now the next iPhone can be even thinner! I can't wait to call 911 and tell them I accidently cut myself with my new razor thin iPhone 12! -_-
Anons need not reply. Questions end with a question mark.
Pushing people to do things 'the right way' is preventing iPhone to turn into Android. This is ONLY targeting lazy developers that haven't updated their app in YEARS (this way of doing it has been possible since 2009 and PushKit as an alternative to polling announced and available since mid-2014).
I'm very glad that VoIP apps don't eat all my battery because they have to poll a service every 5s. Many VoIP apps were simply garbage before iOS 3 and still are on Android, we complain about charging an iPhone once every 2 or 3 days, I had to charge twice a day when I had a particular IM app on an old iDevice, even a current Android I own, doesn't last more than a day when some VoIP/IM apps are open.
Custom electronics and digital signage for your business: www.evcircuits.com
Apple has let developers know that this change was coming for about a year and a half now. We develop a VoIP application and have been making changes well in advance of Apple fully deprecating the older socket mechanism. It does have the downside of giving Apple more control but Apple already has full control over whether you can publish to the App Store, how your UI should look (within reason based on guidelines), not duplicating system functionality, etc. However if this improves battery life and creates applications that are designed in a better fashion then it is positive change.
Apple maintains full control over iPhones. It's not meant to be a computer-like device. Background apps have always been kept on a very short leash. An iPhone is a limited device that only does what Apple allows you to do. If you want a phone that is more like a computer, get an Android.
will this allow Apple, and as is always the case, any U.S. government agencies to get more insight or even subvert the use of secure communication apps?
That is what this about.
This stops off-net VoIP from working.
This is about collecting metadata.
The date on the story is 24 June 2016. Why are you suddenly making a fuss now?
Maybe iOS 11 removes the deprecated API? But I'm sure XCode has been issuing s warning about deprecation all this time.
How much more troublesome would an implementation not relying on constant access to Apple's servers be?
They ARE doing the right thing on Android. The only ones doing something wrong is Apple.
They ARE doing the right thing on iOS. The only ones doing something wrong is google.
Fixed that for you. Update your fucking apps deadbeat.
There is no reason that listening on a socket needs to use ANY battery at all. It WOULD be wise to have a model for checking whether a packet is DoS/dealing with heartbearts before causing it to fire up the real app process, but given that, there is no reason why SIP can't be efficient. If the reasoning for this has anything to do with battery, then it's lazy.
Apple deprecated the old VoIP interface one year ago. Absolutely obvious for anyone interested. But one year warning will obviously come as a surprise to some people. VoIP required that your phone was turned on, your app was running, and regularly pulled requests. An absolute battery eater. The new feature allows your phone to be asleep, use no energy, and wake up immediately when a call arrives.
Thanks for explaining this. I was curious about how that would affect Vonage Extensions, a VOIP app that I use. If the app still uses the old API, whether it would stop working. Same question for WhatsApp. I know that FaceTime audio is an option, but wouldn't work w/ non iPhones.
So how can the operator of a local area network disconnected from the Internet run a private PushKit server?
You could proxy it. It uses HTTP/2 so it can be proxied without requiring any SSL-shenanigans but otherwise that is the simplest method.
Alternatively, the push notification protocol is open, well documented and very simple (JSON back and forth), people have made some reference implementations although most simply rely on the Apple infrastructure. Various commercial MDM have the feature although it's too bothersome for most people to set up so it's generally poorly documented since it's only useful for apps you can import and sign certificates for which would only be available in your own company 'app store'. But it boils down to including the various certificates for your custom implementation, importing them into the phone using a profile (which the user would have to accept). Then your app (and your app only) can talk to 'your' servers instead of Apple's.
Custom electronics and digital signage for your business: www.evcircuits.com
Make the damn phone 1mm thicker and put a bigger battery in it. Apple are determined to offer the smallest battery capacity they can get away with. Courage?
As we can't use the corporate mandated SIP app. Or maybe the iPhonies will just be more of a "special class" and not have to heed to the corporate master.
Android began enforcing very similar rules for real-time things like VoIP in N, O ratchets them down further.
This is apparently the consumer architecture of the moment.
Ya a few years ago apple allowed semi-function multi-tasking. They has to cripple something else to the that power back.
Android has never needed to this.
The app can sleep and activity on the listening port would trigger a listen intent, waking it up.
If your voip app is taking too much battery, then leave a comment and uninstall and find a different solution. People say they do this with whole platforms, so why not an app?
Apple phones are safer than Galaxy Notes because even if the battery does catch fire, it will be a tiny fire that rapidly fizzles out.
Some dumb and dirt Indo-Chimp temple monkey thought this one up. Now how 'bout this chimp-boy: get a shovel and a bucket and start cleaning the shit off the street outside you're front door.
I know you just meant this as a troll but you picked the wrong topic.
If you've been following android, you would know that Android N and O added much the same restrictions as iOS (with regard to apps running in the background or while the phone is dozing)
The problem is it's an adversarial market, from multiple angles: the cell carriers, the OS, and the other apps on the system competing for resources.
In the past, google gave too much freedom and provided a bunch of apis that were broken for one reason or another. The end result is every messaging app had to keep their own connection open. Some carriers had broken NAT boxes that kept losing connections so apps ultimately had to ping faster to stay connected.
The end result was all apps hammering the network to keep connections alive so that they could deliver messages faster than their competition, because nobody had the right incentives (and google couldn't make a proper working Android api for the life of them--GCM/C2DM was at the time very unreliable)
So now they took everything away and everyone has to use GCM (even if you are on a network that blocks GCM ports, too bad). This is why we can't have nice things.
This maybe could have ended differently if Google had started by asking what applications needed and building features *for* developers, instead of throwing together half assed apis that weren't documented properly and expecting that developers would somehow come up with something that worked.
Hasn't Apple always been thought of in terms of a walled garden? Nothing new here.
Technical Q&A QA1938
iOS 10 and the Legacy VoIP Architecture
Q: My VoIP app still uses the legacy VoIP architecture (NSStreamNetworkServiceTypeVoIP and so on). Why, when I build it with Xcode 8 and run it on iOS 10, does it no longer receive calls when in the background?
A: The legacy VoIP architecture was replaced by a new PushKit-based architecture in iOS 8. It was then formally deprecated with the iOS 9 SDK. In iOS 10 it is only available as a compatibility measure; it continues to work (as well as it ever did) if your app is linked with an old SDK, but is disabled if you link with the iOS 10 SDK.
For the moment you can work around this by building your app with Xcode 7. However, this is not a good long-term solution because:
Our experience is that PushKit-based VoIP apps are more reliable and more power efficient than those using the legacy VoIP architecture.
Apple always recommends that you use the latest version of Xcode because it combines the best features and the best compatibility.
Specifically, we encourage VoIP apps to take advantage of CallKit, a new framework in the iOS 10 SDK that radically improves the user experience for VoIP apps. Xcode 8 is the only supported way to use CallKit. Also, be aware that Xcode 7 is not supported on macOS 10.12 Sierra.
At some point support for the legacy VoIP architecture will be removed, whereupon all VoIP apps will have to move to the new PushKit-based VoIP architecture. It’s better to start this work sooner rather than later. Important: This move away from the legacy VoIP architecture is motivated by specific technical concerns. Our experience is that the legacy architecture is unreliable and, when it does work, has a strong negative effect on standby battery life. The new PushKit-based architecture addresses both of these concerns. Some VoIP apps are specifically designed to work in special networks, ones that don’t provide access to the wider Internet. To use PushKit in such an environment you must configure the network to allow iOS devices to access the Apple Push Notification Service. See TCP and UDP ports used by Apple software products for information on how to do this.
For more information about PushKit, see:
PushKit API reference WWDC 2014 Session 712 Writing Energy Efficient Code, Part 2
Document Revision History
Date Notes 2016-10-20 New document that describes limitations of the legacy VoIP architecture on iOS 10.
The current API changes for iOS9 state that -setKeepAliveTimeout:handler: is deprecated.
Up to now, this was the only way that a VoIP SIP app on iOS could maintain its registration with the SIP-server.
This technique is used by various apps like LinPhone and others.
Does anybody have a view on the proposed alternatives by Apple ? Or will SIP be crippled starting from (post-)iOS9 ?
They ARE doing the right thing on Android.
Yeah, they are using Google Cloud Messaging to receive VoIP calls while in Doze mode. Totally different to what you are forced to do on crapple.
...my iphone typically runs 5-7 days from fully charged, and my ipad about a day and a half of continuous use between charges, until i had to install skype and groupme this summre to communicate with my wife while she researching beyond mobile coverage; once those power hogs were running, battery life dropped to barely a day for my iphone and 4-6 hours for my ipad...
Will no longer be under active development, Got married no time.
Then I have to figure out how to rewrite in myself.
I work on Cisco Call Manager and they have been talking about this with customers for the last year. As long as your fairly up to date and have the correct settings Jabber will have no issues and will work with the APN. I would expect all other voip vendors have done the same.