Apps don't need it, and it probably shouldn't be offered. But as things stand, many of the OS's fundamental time APIs return time since boot, and for some reason, most of those aren't even listed as required-reason APIs. The APIs listed are mach_absolute_time() and ProcessInfo.systemUptime, but there is also clock_gettime() with CLOCK_MONOTONIC/CLOCK_MONOTONIC_RAW/CLOCK_UPTIME_RAW, as well more obscure ones like mach_continuous_time(). Therefore:

- 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.

Cupertino, if you're listening, I'm not comfortable with the offset either, that would also do fine as an identifier.

You expect apps to have no access to a simple monotonic timer?

I expect Apple to figure out how to provide apps with such a timer in a way that also prevents them from having access to the system uptime.

If there's a random offset applied, how would they have access to the actual system uptime?

I don’t know, like I said, I expect Apple to figure that out. Their engineers get paid to figure out such problems, not me!

My original response in this thread was to a comment that said, "I'm not comfortable with the offset either".

I expect privacy theater; I err towards having opinions that enforce privacy - i.e. a time that's guaranteed to be x seconds since the app first started after system boot can be used to diminish privacy

Why would you expect privacy theater, though. Apple genuinely tries to frustrate this kind of snooping from (third-party) apps, so if they choose to obfuscate the timer in the first place, I don't see what the point is for them to make it a security theater. The obvious and trivial implementation for this is adding a random number, and that's what any minimally competent dev will do unless specifically told otherwise. So, why would they be told otherwise?

The first-time-the-app-called-the-api-since-device-boot is just as unique as device-boot-time.

It isn't though, at least not in the same way. It's not as if apps can't generate unique identifiers like a UUID. What's important for fingerprinting isn't that it's unique but that it's stable across different apps which this wouldn't be. You could maybe try to eek out a bit of information with "value is greater than" but it would be hard to orchestrate because you can't guarantee that all apps will be first used around the same time.