Developers can add an offset to the values before sending them off the device, and that might be what Apple wants them to do, but these companies have over a decade of pre-existing code that didn't do this. It's not surprising to me that there are things that haven't been updated yet given that Apple only made these requirements public fairly recently.
Something that reduces the granularity a lot, like "time since UTC 00:00:00 on the day of the last device boot", might work.
Things like the user gave permission for camera or microphone and is trying to use them but there's no data coming through. Or really most anything with Bluetooth. Or sometimes their mobile network is being weird.
That probably doesn't justify sending it off the device as a raw value, but Meta really likes driving UI from the server instead of letting the phone be smart. And they have a habit of pushing Apple's limits.
(Disclaimer: I worked for a subsidiary until the end of 2019)
It's the first thing that talk about in the docs https://developer.apple.com/documentation/foundation/nsproce...
- I find it easy to believe that some of the apps may not realize they're using the restricted APIs in an unapproved way.
- Alternately, some of the apps may not be using restricted APIs at all, and instead getting the same information with non-restricted APIs. Not clear if that's even against the rules. It certainly would be extremely sketchy if done as an intentional workaround, but it would be even easier to do accidentally. If you grepped the codebase for uses of the restricted APIs, you wouldn't necessarily find uses of these other APIs.
