[portmanteaufu]

This article is terrible. The change mentioned in the headline isn't explained until the fifth paragraph and beyond.

> Apple’s change involves an API called PushKit, which was originally designed to be used in apps that let people make online phone calls using voice over internet protocol. .... Over time, many apps began using the tool for purposes other than Internet phone calls, including encrypted messaging apps that found it was the best method for decrypting messages in the background on iPhones. .... But app developers could also use PushKit to collect information about the location of users and other sensitive data, which concerned Apple. .... With iOS 13....the company is finally cutting off developers from using PushKit for any purposes other than internet phone calls.

[msie]

Wow, and to think of all the times I've held myself back colouring within the app guidelines. Meanwhile other app developers are abusing the apis to no end.

[Icathian]

Well sure, but on the other hand now all your stuff isn't broken. Give and take, I think.

[AmericanChopper]

Had a similar situation once. Apple announced a rule change that impacted our business. We talked to them and realized we had to suck it up. We spent 6 months completely redesigning our app to fit in with the new guidelines. Meanwhile we found out our competitors spend 6 months doing nothing but complaining to Apple. Apple reneged on the change. We lost 6 months dev time trying to comply with the new rules in good faith, our competitors spend those 6 months doing their regular work on new features.

[pfranz]

Working the refs works way more often than people think.

[hosteur]

What was the change?

[kabes]

Except if he was using PushKit in a compliant way.

[fooey]

Approval process roulette is exciting enough when you think you're following the guidelines.

[turdnagel]

Came here to say the same thing. Even this description is _really_ light on details.

I'd love to see a technical breakdown of this problem. iOS 13 has a background task API - why can't that be used?

Incoming notifications can trigger application code to run - why can't that method be used?

[lacker]

iOS 13 has a background task API - why can't that be used?

The iOS 13 background task API limits your background tasks to a few minutes. So, they're useful for short batch tasks you don't want to interrupt when the app closes, like cleaning up a database. They aren't so useful for listening for a notification that could come after hours of inactivity.

Incoming notifications can trigger application code to run - why can't that method be used?

This is probably what apps will do in response to the rule changes. It isn't ideal, though. Incoming notifications can trigger application code to run, but only for notifications that include a visible display to the user. This means that a server has to differentiate between different types of data on their network, like knowing the difference between a new user message and a read receipt. It is not ideal for privacy to expose that information to the server.

So, this isn't the end of the world, but it will hurt the privacy model of non-iMessage private messaging apps.

[prophesi]

Honestly, in terms of privacy, I think it's a decent trade-off (from what I gathered from this sparse article).

PushKit

Pros:

- Apps and their servers can be developed in a manner wherein the server doesn't know if it's sending a message or a read receipt (aka, no metadata leak).

Cons:

- "[...] developers could also use PushKit to collect information about the location of users and other sensitive data"

So with the traditional Notifications API, you lose that pro, but now _all_ of your apps with potentially ill-intentions can no longer glean your location and other data.

Edit: Though, another huge con to this is the amount of dev hours to abide by this change. It's already a pretty sizable engineering task to create a fast, secure, and end-to-end encrypted messaging app.

[JustSomeNobody]

> This is probably what apps will do in response to the rule changes. It isn't ideal, though. Incoming notifications can trigger application code to run, but only for notifications that include a visible display to the user. This means that a server has to differentiate between different types of data on their network, like knowing the difference between a new user message and a read receipt. It is not ideal for privacy to expose that information to the server.

I guess I still don't get it.

A notification comes into the iPhone. iOS wakes the app. The user clicks the notification, the app opens, the user reads the message and the app sends a read receipt to it's own servers.

A new message would just be a new message. The user would type it and hit send. The app would send it to it's servers which would then use the push api to send a message to the recipient.

Edit: Ok, I get it. The point is one doesn't want a server knowing the difference between the two types of messages. That's a leak of metadata.