[EGreg]

I am a developer of a messaging app downloaded so far by 5 million users around the world. I was very concerned about this news and looked into it.

Apple is simply doing away with silent push notifications through the VoIP API. Apps can still register an extension that will process arbitrary push notifications that result in a visible notification to the user.

If the application needs to silently send something to the app, it can do so with background modes, such as sending a push notification via PushKit with content-available: 1. The OS then schedules when the download may happen. If the download doesn’t happen before the app is started, the app can simply send a request at that time and download it, just like any other content-available thing.

There is no legitimate use I can think of for silently sending data using VoIP push except when you’re on a call and you want to send WebRTC type data (eg say someone joined the call).

But here is the kicker: PushKit notifications are reputed to be delivered on a lower priority basis than VoIP notifications. And that’s the big thing. Apple can simply slow them down to make FB messages arrive slower than iMessage for example.

[mapmap]

Regarding your last paragraph, it's actually more severe:

Eventually the silent push notifications (content-available: 1) will not be delivered to the app at all. They are throttled by how much energy the app uses when launching in response.

Send too many or do too much with each one, and you'll find iOS no longer launches the app. The limits are not documented.

The maddening part is everything will work fine while you're developing and have your phone plugged in to power. You'll only notice this on battery power.

[crummy]

Could Apple have slowed down VoIP notifications before, to negatively affect FB messages vs iMessage?

[azinman2]

While I don’t work on this at Apple, I’ve never once heard of anything being designed to punish a competitor like that.