Nothing prevents applications from just calling the underlying methods mentioned in the article, so that can’t be it. The author even benchmarked these!
Nothing? FTA: “The downside to calling mach_absolute_time directly, though, is that it’s on Apple’s “naughty” list – apparently it’s been abused for device fingerprinting, so Apple require you to beg for special permission if you want to use it”
All the other methods "above" mach_absolute_time are still allowed though, including clock_gettime_nsec_np that's only ~2x slower than mach_absolute_time. While the Swift clock is ~40x slower than mach_absolute_time. I don't see how intentional slowdown for fingerprinting protection can be the cause.
All of the new privacy declarations are silly, but this one is especially ridiculous.
I'm pretty sure I can trigger a hit to the naughty API just by updating a @Published var in an ObservedObject. For those unfamiliar with SwiftUI, this is the most basic way to tell the system that your model data has changed and thus it needs to re-render the view. Pretty much every non-trivial SwiftUI app will need to do this.
but date and clock_gettime are still accessible and not much more overhead than the Mach API call. Additionally as I mention in another comment, this would have to be about Meltdown, not Spectre, and Meltdown is mitigated in the kernel through other techniques without sacrificing timers.
It isn't difficult to be granted this permission. All an app needs to do is supply a reason defined in https://developer.apple.com/documentation/bundleresources/pr... as to why it's being used in the app's bundled PrivacyInfo.xcprivacy file, which could be disingenuous.
In addition, if you get caught lying about this, your app may be nuked and your developer account terminated. May not be a big hurdle, but definitely can hurt if you have many users.