The "sysctl.proc_translated" suggestions are only going to tell you if the an Intel (x86_64) binary is running via Rosetta 2 on an Apple Silicon based Mac.
If you want to check the architecture at runtime, you can use uname(_:) to do just that. I added an extension to ProcessInfo to provide a bit more of a modern API for it:
extension ProcessInfo {
		/// Returns a `String` representing the machine hardware name or nil if there was an error invoking `uname(_:)` or decoding the response.
		///
		/// Return value is the equivalent to running `$ uname -m` in shell.
		var machineHardwareName: String? {
				var sysinfo = utsname()
				let result = uname(&sysinfo)
				guard result == EXIT_SUCCESS else { return nil }
				let data = Data(bytes: &sysinfo.machine, count: Int(_SYS_NAMELEN))
				guard let identifier = String(bytes: data, encoding: .ascii) else { return nil }
				return identifier.trimmingCharacters(in: .controlCharacters)
		}
}
On an Apple Silicon based mac, this will return arm64 whereas on an Intel one it'll be x86_64. Be aware however that if your program is running in Rosetta then it'll return x86_64 again... You could combine it with the other solutions to check that it's also not running as translated to overcome that edge case.
liamnichols_
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
From
Bristol, England
Post
Replies
Boosts
Views
Activity
The email only mentioned the app itself and the app's extensions.
If your third party dependencies are statically linked to your app/extension targets (the default for most SPM packages, or when using linkage: :static in CocoaPods), you are probably seeing this because the contents of the third party code is embedded within you app/extension binary rather than embedded in the /Frameworks directory as it's own dynamic framework.
This results in the confusing warning message that makes it sound as if the usage exists within your own code.
I'd love for somebody to correct me, but I think that the only solution today is for you crawl through the PrivacyManifest.xcprivacy file for each of your third party dependencies and to copy the required API usages into your own PrivacyManifest.xcprivacy files in your app and extension targets.
If this sounds frustrating to you, please consider submitting a feedback to Apple as well. If you are not sure what to write, I have a template and instructions here: https://liamnichols.eu/2024/03/22/privacy-manifests.html.