It's not the case that they would need to give up encrypted notifications. Developers can support end-to-end encrypted notifications by creating a UNNotificationServiceExtension[1]. This is an extension which receives and can mutate the notification before it's shown to the user.

[1]: https://developer.apple.com/documentation/usernotifications/...

Straight from Apple's documentation:

> For example, you could use the extension to decrypt an encrypted data block or to download images associated with the notification.

Thanks for the link. So when FB/WhatsApp will adapt it will work as before. That's great news.

It has nothing to do with end-to-end encryption: they’re abusing the VoIP feature to stay running in the background, which is trading battery life for better surveillance of your activities. Apple is doing it to _protect_ privacy by closing one of the ways unscrupulous app developers keep trackers running.

It has everything to do with end-to-end encryption. Prior to iOS 10, the only way to display notifications for end-to-end encrypted chat without giving Apple a plaintext copy of everything in the notification was to abuse the VoIP feature. More specifically, the "PushKit VoIP API" Facebook's spokesperson mentioned allowed services to push down an opaque blob of data and have their apps immediately wake up in the background, do some processing (such as decryption), maybe get more data from the network, and create a notification. This was intended to support incoming voice calls but worked great for end-to-end encrypted text chat. Now Apple are cracking down on the use of that VoIP background functionality for anything but voice calls.

It might be possible for companies like Facebook to rewrite their code to use an iOS 10+ Notification Service app extension to decrypt the notifications instead, but that requires major code changes and has additional limitations.

Also, from what I can tell Facebook Messenger etc haven't had access to the old APIs which just let VoIP apps run in the background all the time since about 2016. That's not available for apps linked to the iOS 10 API and they've been using the iOS-10-only CallKit since about that time.

> It might be possible for companies like Facebook to rewrite their code to use an iOS 10+ Notification Service app extension to decrypt the notifications instead, but that requires major code changes and has additional limitations.

Perhaps, but iOS 10 is now 3 years old; Facebook has had plenty of time to make those major code changes, as opposed to continuing to use VoIP push notifications for things other than VoIP.

Facebook aren’t obliged to make a change just because they can. Taking something that works and changing it for its own sake is something people very often get annoyed about.

> Taking something that works and changing it for its own sake

That's a somewhat misleading way to characterize this: VoIP apps are still going to be just fine using the VoIP API. The question is whether legacy code should preclude Apple taking steps to act on their users' behalf. Given the number of people I know who uninstalled Messenger so their phone could make it through the workday without a charge, I'm pretty sure most people will shed no tears for someone at Facebook having to do the job they are very well paid to do.

I don’t get what you’re trying to say? The GP says the new api which Facebook should use has been available 3 years, implying that fb ought to have made the change long ago. I say they had no reason to make the change in the last three years [because Apple are dropping support for the old api now and only announced this recently]. And you say that’s wrong (so FB should have made the change 3 years ago) because ... the app will have been fine? Or because Apple behave nobly? I don’t see how it follows.

I’m saying that Facebook was using an API for something other than what it was designed for, and thus I don’t feel much sympathy for them having to change their code when the API contract is more strictly enforced. It’s just a cost of doing business at that point.

> Prior to iOS 10, the only way to display notifications for end-to-end encrypted chat without giving Apple a plaintext copy of everything in the notification was to abuse the VoIP feature.

It’s not the only way, but VoIP is the most reliable way. You can accomplish the same thing with encrypted silent push notifications, that wake up the app and trigger a decrypted local notification. Problem is that silent push notifications aren’t reliable because they don’t always wake up the app (which is throttled by the OS).

> It has everything to do with end-to-end encryption.

Hey, I just noticed that I never responded to you directly: my objection to the comment I replied to wasn’t because it didn’t affect some end-to-end encryption apps but that Apple wasn’t acting against them because they implemented encryption. They’re going against everything using the VoIP API for non-VoIP features and there’s an official replacement API available, so the language casting it as a threat to privacy seemed unfounded.

The use of voip mode is well established technique for building encrypted messaging apps on iOS, and its unsurprising that whatsapp is built around it, especially when you consider that whatsapp is a voip app. No conspiracy theories are necessary.

Are Signal and other messaging apps relying on this feature and do they offer VoIP functionality?

As far as I can tell, that's a yes to both: Signal supports VoIP calls, they're definitely using the PushKit VoIP API, and I assume they're using that API for both text notifications and calls since the code doesn't have any reference to the other API they could use.