`tracing_appender` triggers Apple `NSPrivacyAccessedAPICategoryFileTimestamp` API usage warning

[jamilbk]

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 the NSPrivacyAccessedAPICategoryFileTimestamp 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. :-(

[davidbarsky]

.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.

[jamilbk]

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