5 ms·

File timestamp and free space are likely to be used by just about any app that imports a caching library, e.g. for images. I predict a flood of app rejections

File timestamp and free space are likely to be used by just about any app that imports a caching library, e.g. for images. 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.

542458 3y ago
File timestamp is a hard one, I’m not really sure what the “correct” way to implement that is while preserving privacy. Maybe hiding timestamps on files not owned by that app? 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.
- iamcalledrob 3y ago
  Re: timestamps, the app is already sandboxed and is limited in the files it can read. It's strange that they're seemingly locking down timestamps tighter than the data itself? 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.
- fbdab103 3y ago
  For disk space, you think they could just report sufficiently rounded numbers (eg increments of 256MB free).

542458 3y ago

File timestamp is a hard one, I’m not really sure what the “correct” way to implement that is while preserving privacy. Maybe hiding timestamps on files not owned by that app? 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.

iamcalledrob 3y ago
Re: timestamps, the app is already sandboxed and is limited in the files it can read. It's strange that they're seemingly locking down timestamps tighter than the data itself? 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.
fbdab103 3y ago
For disk space, you think they could just report sufficiently rounded numbers (eg increments of 256MB free).