5 ms·

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 Pu

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 7y ago
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 7y ago
  Well sure, but on the other hand now all your stuff isn't broken. Give and take, I think.
  - AmericanChopper 7y ago
    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.
    - hosteur 7y ago
      What was the change?
    - pfranz 7y ago
      Working the refs works way more often than people think.
  - kabes 7y ago
    Except if he was using PushKit in a compliant way.
- fooey 7y ago
  Approval process roulette is exciting enough when you think you're following the guidelines.
turdnagel 7y ago
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 7y ago
  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.
  - JustSomeNobody 7y ago
    > 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.

msie 7y ago

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 7y ago
Well sure, but on the other hand now all your stuff isn't broken. Give and take, I think.
- AmericanChopper 7y ago
  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.
  - hosteur 7y ago
    What was the change?
  - pfranz 7y ago
    Working the refs works way more often than people think.
- kabes 7y ago
  Except if he was using PushKit in a compliant way.
fooey 7y ago
Approval process roulette is exciting enough when you think you're following the guidelines.

turdnagel 7y ago

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 7y ago
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.
- JustSomeNobody 7y ago
  > 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.