Hacker News new | comments | show | ask | jobs | submit login
iOS 10 quietly deprecated a crucial API for VoIP and communication apps (slashdot.org)
29 points by MilnerRoute 100 days ago | hide | past | web | 13 comments | favorite

Looks like this prevents the workaround where devs would register their app as a VOIP app so they could use the persistent background socket allowed for VOIP apps. It's not an abuse Apple was really permitting anyway. I was going to try to use this trick in a mobile game so I didn't have to reconnect the websocket everytime the game gets backgrounded but figured Apple would crack down in one way or another even if I could sneak it by.

It really sucks that in addition to taking away the ability for users to make their own decisions and tradeoffs with respect to functionality vs data usage and battery life this also forces developers to build systems that are centralized in ways that undermine user privacy and create easy-to-block bottlenecks :/.


Note that enterprises, and expert users, can still provision a custom push profile that routes these notifications through their own hosted push server rather than through Apple’s. This is not useful for App Store users, but App Store users are also not likely to know or care about this change.

So in your "CORRECT CORRECT CORRECT" version of the world, every single person who wants to make a VoIP call will have to buy an Apple developer account and set up a "custom push profile" with a "their own hosted push server" (which I guess I will assume is truly hosted and doesn't go through Apple, even though that feels unlikely to me) that the other person will have to install on their phone first in order to make an end-to-end encrypted phone call? I hope you understand that this is even worse than just having a centralized signaling server, and is "complete bullshit".

I don't agree with what you wrote, but that's as far as I can figure out how to respond, sorry.

Can you provide a link to more information on this capability? It sounds very useful, but I cannot find anything about it in Apple's documentation.

Aw, hell, I misunderstood for YEARS. You can run your own local listener, but it delivers to devices through APN. Sorry.

So do I understand this correctly? For a messenger app would that mean that, unless the app is in foreground, every single chat message will need to be delivered via Apple's push servers?

The push notification need not contain the message, no, but it’s often more efficient that way.

It's always been like this for chat applications; the API being discussed is for VOIP calls.

For chat apps, you use push notifications to alert users and wake up the app, that can do its own downloading through its own protocol. You don't need to use pushes to actually deliver content unless it's relevant to show to the users

In other news, it's not really feasible to have a multitude of apps that all claim to have to run in the background on a mobile device.

If you want to try anyway or you're in one of the rather contrived situations where Apples solution doesn't work, consider an Android device.

Contrieved situations like... taking a voip call?

More like, “my employer blocks Apple services, but I still want to use an unsupported mobile VoIP client at work”.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact