I was surprised to see Apple exposing the device boot time. Not sure why a typical app would need this, and in a world in which iPhones are infrequently rebooted, the combination of this with other fields must indeed be very deterministic.
Most ways to collect boot time are a "Required Reason API," so they declare through NSPrivacyAccessedAPITypeReasons, meaning AppLovin apps are (unsurprisingly) lying about what they are doing with the data. There's a fair amount of research into this, for example at https://mysk.blog/2024/05/03/apple-required-reason-api/ and https://blog.appicaptor.com/2025/02/05/apples-required-reaso... (which also documents a workaround that Apple's static analysis tools didn't detect at the time).
My general conclusion is: it's stupid that Apple continue to allow this and Trust Us Bro is not a good permission system to allow app developers do shady things, especially when research indicates that they are, unsurprisingly, doing shady things. Apple's static analysis based App Store approval system is also historically swiss-cheesey and I know they could do better. Overall, thematically a black mark on Apple, which has always been surprising for me because they tend to genuinely care about privacy in many other facets.
I had no idea Apple exposed that information. And they're clear that the data _should not be sent off the device_:
> 35F9.1
> Declare this reason to access the system boot time in order to measure the amount of time that has elapsed between events that occurred within the app or to perform calculations to enable timers.
> Information accessed for this reason, or any derived information, may not be sent off-device. There is an exception for information about the amount of time that has elapsed between events that occurred within the app, which may be sent off-device.
> 8FFB.1
> Declare this reason to access the system boot time to calculate absolute timestamps for events that occurred within your app, such as events related to the UIKit or AVFAudio frameworks.
> Absolute timestamps for events that occurred within your app may be sent off-device. System boot time accessed for this reason, or any other information derived from system boot time, may not be sent off-device.
I was surprised to see Apple exposing the device boot time. Not sure why a typical app would need this, and in a world in which iPhones are infrequently rebooted, the combination of this with other fields must indeed be very deterministic.
Most ways to collect boot time are a "Required Reason API," so they declare through NSPrivacyAccessedAPITypeReasons, meaning AppLovin apps are (unsurprisingly) lying about what they are doing with the data. There's a fair amount of research into this, for example at https://mysk.blog/2024/05/03/apple-required-reason-api/ and https://blog.appicaptor.com/2025/02/05/apples-required-reaso... (which also documents a workaround that Apple's static analysis tools didn't detect at the time).
My general conclusion is: it's stupid that Apple continue to allow this and Trust Us Bro is not a good permission system to allow app developers do shady things, especially when research indicates that they are, unsurprisingly, doing shady things. Apple's static analysis based App Store approval system is also historically swiss-cheesey and I know they could do better. Overall, thematically a black mark on Apple, which has always been surprising for me because they tend to genuinely care about privacy in many other facets.
I had no idea Apple exposed that information. And they're clear that the data _should not be sent off the device_:
> 35F9.1
> Declare this reason to access the system boot time in order to measure the amount of time that has elapsed between events that occurred within the app or to perform calculations to enable timers.
> Information accessed for this reason, or any derived information, may not be sent off-device. There is an exception for information about the amount of time that has elapsed between events that occurred within the app, which may be sent off-device.
> 8FFB.1
> Declare this reason to access the system boot time to calculate absolute timestamps for events that occurred within your app, such as events related to the UIKit or AVFAudio frameworks.
> Absolute timestamps for events that occurred within your app may be sent off-device. System boot time accessed for this reason, or any other information derived from system boot time, may not be sent off-device.