- File timestamp
- System boot time
- Disk space
- Active Keyboard
- User Defaults
Makes sense but I imagine some of them will also be very annoying, it depends how strict Apple are about giving permission. If you have to maintain a separate record of file change time stamps for example that’s going to get pretty tiring.
I predict a flood of app rejections due to developers unknowingly using these APIs as part of a dependency.
Things like stat() are so fundamental that you'll pretty much always find them somewhere in a moderately sized code base.
But free space (if being used for caching purposes): Why not just try to save to .cachesDirectory? If there’s no space the file save will fail, which is fine, your app should handle that anyways. If there’s low but sufficient space that fine, the OS will evict the file soon enough.
For free space, it's pretty common for iOS apps to restrict functionality when your device is critically low on space -- because having most disk writes fail can be very difficult to handle.
You also might want to implement a cache policy that's "greedier" when there's plenty of free space. I think there are plenty of reasons to want to know how much free space is available.
I feel like offering lower fidelity values may be a better of handling these privacy concerns rather than adding further complexity to the already onerous app review process.
For example, for files your app doesn't own, round timestamps to the nearest second, and free space to the nearest 100mb. Most legit use-cases won't need more than this level of fidelity.
Mark my words, this goes two ways: 1. Apple rolls it back, devs feel like they have power, Apple does security/Dev theater over the whole ordeal. 2. Massive App store review issues for 99% of apps on the store.