Open jamilbk opened 3 months ago
.metadata().ok()
is an API coming from std
; which makes things... complicated. I'd recommend making your own appender that is compliant with Apple's privacy manifests.
Yeah, we ended up just submitting a PrivacyManifest because even std
pulls in "offending" API calls.
Here is what Apple approved if it's helpful for anyone else:
https://github.com/firezone/firezone/blob/main/swift/apple/PrivacyInfo.xcprivacy
Feature Request
Crates
tracing_appender
Motivation
Apple's new Privacy regulations force developers to now declare a "Privacy Manifest" file with details on why the API in question is needed.
tracing_appender
seems to use theNSPrivacyAccessedAPICategoryFileTimestamp
API in its operation here.This creates a hurdle for building applications for Apple platforms that use tracing_appender as it reads file timestamps by default.
See the error message we received from the App Review team.
Proposal
I suppose there's not a great solution for this. In our case, the filenames themselves have the creation timestamp in them, so tracing_appender may be able to use that.
Otherwise, perhaps exposing an option to prevent this from being linked in at compile-time would be sufficient, like perhaps behind a feature. We tested without rollover (so this codepath should not be hit at runtime) and it still triggered Apple's warning.
Alternatives
Unfortunately we're considering just removing tracing_appender altogether and rolling our own non-blocking log writer that doesn't read file timestamp metadata. :-(