Hello, I've been going through Apple's documentation on describing the use of required reason APIs in the privacy manifest file, and I have a question about handling APIs from third-party SDKs. If we've already integrated the manifest file provided by the third-party SDK into our project, do we still need to list the reasons for the APIs from the third-party SDK in our app's manifest file?

Hi Apple team. Our library calls stat/fstat to get the file size, not the timestamp. In this case there is no applicable reason for NSPrivacyAccessedAPITypeReasons. Will the app still be rejected if I don't set something for NSPrivacyAccessedAPIType? Or should I write a reason for lying? The documentation seems to be contradictory.

I work for a company that specializes in providing fraud detection With Apple's recent announcement regarding the introduction of privacy manifests, we are want to ensure that we are fully compliant with all requirements and standards. Our company provides third-party libraries for various businesses to integrate into their platforms, primarily to detect and prevent fraudulent activities. This data is solely used for fraud detection and prevention, and not for advertising or any other purposes. Given the outlined context, we seek clarity on the following points: As a third-party library provider focused on fraud prevention, do we need to disclose the specific data points we collect under the new privacy manifest requirements? Are there any particular considerations or exemptions for companies that use data exclusively for security and fraud prevention purposes and not for advertising or other unrelated functionalities? Same questions but regarding required reason API I have wrote the support but did not get any message back, so want to try my chance on the forum

Hi Apple Team, As for considering allowed reasons for accessing required reasoning API, fraud detection is not listed as allowed reason or any exception for scenarios involving fraud detection described in the document. I believe it is necessary to add, fraud detection as allowed reason or grant exception for scenarios involving fraud detection as valid usage, as these API's play crucial role in detection and prevention of frauds. API's playing crucial role in fraud detection and prevention. System boot time APIs User defaults APIs Disk space APIs Thank you.

From this document Note : You only need to supply NSPrivacyAccessedAPITypes for apps and third-party SDKs on iOS, iPadOS, tvOS, visionOS, and watchOS. From this video iOS 17 automatically blocks connections to tracking domains that have been specified in any privacy manifest included in your app It seems iOS needs NSPrivacyTrackingDomains to block connections when user has NOT provided tracking permission. But the document says only needs NSPrivacyAccessedAPITypes to supply. As a SDK(for iOS) developer, I would like to know which keys to provide for Privacy Manifest. Also, I made an app including xcprivacy to test NSPrivacyTrackingDomains to block connections but it connected to the domain. Is this feature already available in Xcode15 beta 5 (iOS 17 beta 5)?

Hello everyone, According toPrivacy manifest files | Apple Developer Documentation, the following targets require a privacy manifest: Apps and third-party SDKs — distributed as XCFrameworks, Swift packages, or framework bundles — can contain a privacy manifest file, named PrivacyInfo.xcprivacy. From this statement, I know "Swift packages" are included under "third-party SDKs". However I'm not clear what kind of "Swift packages" are considered as "third-party SDKs". Referring to the answer, Digital signatures available for S… | Apple Developer Forums, it's mentioned that digital signatures is focused on binaries. From this, I understand that Privacy manifest is mandatory for Swift packages containing binaries. However, I'm unclear about the necessity of the Privacy manifest in the following two scenarios, for example: Is a privacy manifest required for open-source Swift packages that only provide source code? For local swift packages used within an app (like for modularization) that contain only source code, is a privacy manifest necessary? If anyone is familiar with this, your insights would be greatly appreciated.

In the Required Reason API doc, the UserDefaults section defines NSPrivacyAccessedAPITypeReasons CA92.1: Declare this reason to access user defaults to read and write information that is only accessible to the app itself. This reason does not permit reading information that was written by other apps or the system, or writing information that can be accessed by other apps. If I store a user generated string in UserDefaults, later on fetch it within the same app, send it to my backend component, and lastly my backend component share the string with 3rd party developers, do I still fall into the CA92.1 category? In other words, do I need to submit an approval request for this kind of usage? My understanding is this usage still falls into CA92.1 because it does not access device signals for fingerprinting purposes, but I am not sure. Please advice. Thanks!

For an ad SDK that shows web ads in WKWebView, if it does not know what tracking pixels will be in the web ads, is it still responsible for reporting Tracking Domains in the Privacy Manifest? If yes, how?

I've set up a privacy manifest file in my SDK, which I'm developing in Xcode 15 beta 4, and built an xcframework. I verified that PrivacyInfo.xcprivacy exists in the xcframework. In state verifying the existence of PrivacyInfo.xcprivacy in xcframework, I incorporated the built xcframework into a test app for operation check, created an archive, and outputted a report from "Generate Privacy Report". Despite having a privacy manifest file set up in the test app, when I checked the report, I was able to confirm the contents of the test app's privacy manifest file but not the contents of the privacy manifest file I configured in the SDK. I understand that the SDK's privacy manifest file is merged with and outputted from the privacy manifest file of a project that incorporates the SDK. Am I mistaken?

Apple recently announced some features to make device fingerprinting more difficult on their devices. The use of certain APIs that facilitate device fingerprinting will require justification. This technique is frequently used to prevent fraud and abuse in applications. For example, a device used to create and access multiple fake accounts to engage in fraudulent activities should be able to be identified and blocked. In the documentation on 'User privacy and data use', use cases related to fraud detection are not considered 'tracking' and are allowed. However it is not clear wether or not what applies to tracking can also be applied to fingerprinting. According to Apple's policies, is it possible to use device fingerprinting for fraud detection purposes?

I'm really excited by the idea of the privacy manifests, and really all the work Apple is doing to keep users protected. I work on the Mozilla VPN, and Mozilla shares Apple's commitment to privacy. We use Adjust to determine referrals for new subscriptions. But because of our commitment to privacy: After a user subscribes, we never activate the Adjust SDK on future app runs. We proxy the Adjust network call through our app, and strip out most of the fields it was going to send to the Adjust server. We keep a small handful of fields that are necessary for attribution (and even publish the list of those fields). Further, we don't send the Adjust network request (which has been stripped down) directly to Adjust's servers, we proxy it through our own server first. This both keeps user IP addresses private, and allows us to further strip out payload values on the server (or stop sending data onto Adjust entirely) if ever needed. Ultimately, this means Adjust's future privacy manifest likely won't be accurate for our app, as we're significantly modifying the Adjust SDK behavior and data collection. Questions: Will we be able to note in Xcode that the listed privacy manifest doesn't apply in our case? If there are future plans to compare privacy manifests with app nutritional labels in the App Store Review process, is it possible to consider this use case in your planning? Thanks!

As of Xcode 15, Apple supports adding Privacy Manifests to SDKs. We develop an SDK that consists of several components (frameworks) for which we would like to add a Privacy Manifest. That works fine for our local builds, but we distribute our SDK via CocoaPods, which generates a single framework with the sources of all our components. This single framework currently does not have a Privacy Manifest. How would we be able to provide Privacy Manifests when using CocoaPods for distribution?

Hi, team. I tried including Privacy Manifest in my sample app and generating a privacy report. But "The archive does not contain any PrivacyInfo.xcprivacy files." error occurred when I tapped "Generate Privacy Report" button on Xcode Organizer. Is there something wrong? Could you tell me how to fix it? Here are screenshots of my Xcode and Xcode Organizer. Thank you.

The video mentioned the following documentations but I can't find them anywhere ( developer.apple.com and Google): App privacy details on the App Store Required reason APIs Privacy-impacting SDKs Does anyone know where they are, or when they will be available? Thanks!