I have a question about the privacy manifest file (PrivacyInfo.xcprivacy).
If the third party SDK used in our app is not updated (or the repository is read-only and not permanently updated), can we include the description for the third party SDK in the privacy manifest file of our app?
Post
Replies
Boosts
Views
Activity
① Regarding the conditions for adding the privacy manifest file
We publish iOS apps on the AppStore that incorporate privacy manifests and SDKs (Alamofire, etc.) that are subject to signatures.
NEWS Regarding "Requirements for third-party SDKs that will be applied soon", we have already released the SDK with the target SDK installed, so "Even if the app itself is updated, the privacy manifest will not be included in the target SDK. I understand that it is possible to publish it to the AppStore without any problems without including it, but is this correct?
We believe that this app's update does not fall under the "submit new apps" or "submit an app update that adds one of the listed SDKs as part of the update" and is therefore not subject to the update.
Based on the above, please answer which of the following is correct?
Answer A: There is no need to add a privacy manifest to the target SDK if it has been published with the target SDK incorporated.
Answer B: A privacy manifest needs to be added to the target SDK even if it has been published with the target SDK incorporated.
②-1 About SDK signature
Regarding the statement "Any version of a listed SDK, as well as any SDKs that repackage those on the list, are included in the requirement", unless the SDK distributor repackages and incorporates it, there is no SDK signature. But I wonder if it will be rejected by the AppStore?
Based on the above, please answer which of the following is correct?
Answer A: A repackaged SDK will not be rejected by the App Store even if it does not have an SDK signature unless it is included.
Answer B: If you do not include the repackaged SDK, it will be rejected by the AppStore.
②-2 About SDK signature
Only .xcframework is recognized as the SDK format that requires a signature, but is this correct? In other words, if you are using a binary format such as .framework, .a, or .b, or if you are using an SDK but are not using a binary format and are writing the source code directly as the application source code. In this case, there is no need for an SDK signature and there is no recognition difference.
Based on the above, please answer which of the following is correct?
Answer A: The only SDK format that requires a signature is .xcframework.
Answer B: Apps using binary formats such as .framework, .a, and .b cannot be signed, so apps using those frameworks will not be accepted on the App Store.
③ Regarding SDKs other than “SDKs subject to privacy manifest and signature”
NEWS For SDKs that are not listed in "Requirements for third-party SDKs that will be applied soon", it is my understanding that adding a privacy manifest file and signing an SDK are not required (= publishing to the App Store is possible even if they are not done). Isn't there a difference?
(The above is interpreted from the wording of the relevant page, ``From Spring 2024 onward, regarding the SDKs listed below.'')
Based on the above, please answer which of the following is correct?
Answer A: For SDKs that are not listed, adding a privacy manifest file and signing the SDK is optional (even if it is not supported, it can be published on the AppStore)
Answer B: Even for SDKs not listed, adding a privacy manifest file and signing the SDK is required.
④-1 APIs that require a reason
If it is not necessary to add the target SDK manifest file for reasons such as ① above (the target SDK is already installed and does not fall under "submit an app update that adds one of the listed SDKs as part of the update" case), is it possible to publish the SDK to the AppStore in a state where there is no description of the API that requires a reason?
Based on the above, please answer which of the following is correct?
Answer A: If the additional requirements of the privacy manifest do not apply, there is no need to describe the API that requires a reason for the applicable SDK.
Answer B: Even if the additional requirements of the privacy manifest do not apply, APIs for which a reason is required for the applicable SDK must also be described.
④-2 APIs that require a reason
Is it possible to publish to the AppStore even if I write the contents of "API requiring a reason" in the privacy manifest of the target SDK as part of the app itself?
(Because the repository becomes read-only due to AFNetworking, etc., it is not expected that a version with a manifest file added will be released)
Based on the above, please answer which of the following is correct?
Answer A: It is possible to publish to the AppStore even if the contents of "API that requires a reason", which should be written in the privacy manifest in the target SDK, are written in the app itself.
Answer B: If you include the content of "API requiring a reason" in the privacy manifest of the target SDK as part of the app itself, it will be rejected.
⑤ Regarding SDKs used by third-party SDKs
If an SDK listed in the list is used inside a third-party SDK, it will not be subject to AppStore rejection even if the third-party SDK does not have a privacy manifest or is not signed. But isn't there a difference? (Only the third-party SDK vendor can know about the SDK used inside the third-party SDK, and it is not something that can be guaranteed by the developer of the application that incorporates it.)
Based on the above, please answer which of the following is correct?
Answer A: The developer of the application that incorporates the SDK used internally by a third-party SDK does not have to guarantee it.
Answer B: The SDK used internally by a third-party SDK must be guaranteed by the developer of the application that incorporates it.
■About SDK signature
Regarding the "Upcoming third-party SDK requirements" announced on December 7th, the method for signing only .XCFramework is described below.
https://developer.apple.com/documentation/Xcode/verifying-the-origin-of-your-xcframeworks
Could you please tell me how to sign for each of the following cases of how to embed a third-party SDK (hereinafter referred to as SDK) in a format other than the above (other than .XCFramework)?
Case 1: SDK signature method when the SDK source code itself is embedded in the app itself (Reachability etc.)
Case 2: SDK signing method for .framework
■About the description of “Upcoming third-party SDK requirements” in the 12/7 announcement
https://developer.apple.com/support/third-party-SDK-requirements/
Does the following sentence on the above page mean ① or ② in the following understanding?
English "Signatures are also required in these cases where the listed SDKs are used as binary dependencies."
Japanese: "Signing is also required when the SDKs listed below are used as binary dependencies."
Understanding 1: SDK signature is required only if the SDK is used as a binary dependency
Understanding ②: An SDK signature is required not only when the SDK is binary dependent, but also when using other methods (such as an embedding method where the SDK source code itself is placed)
■How to incorporate privacy manifest for SDK by app developer
In the case of SDKs such as AFNetworking and Reachability, whose repositories are frozen and there is currently no hope that a version compatible with manifest files will be released, is it possible to release the application even if the application developer takes the following steps?
Countermeasure No. 1: When integrating with Cocoapods, place PrivacyInfo.xcprivacy directly under the Pods/SDK directory
Countermeasure 2: Add SDK information to the app's privacy manifest
■About the content you answered last time
"Question 3.1: APIs that require a reason / Question 3.2: APIs that require a reason / Question 5: Third party > - About the SDK used in the SDK
Since our department does not have this information, please use the forum site below where you can exchange information with developers and our engineers.
We have also posted on the forum as shown in the URL below, but we have not received any responses.
https://developer.apple.com/forums/thread/741961
https://developer.apple.com/forums/thread/743329
If we do not receive a response at this time, our company will be unable to develop and provide services, so would it be possible for you to respond by the end of December?
https://developer.apple.com/news/?id=3d8a9yyh
In the above, in "uploading new apps and updating published apps" after May 1st,
“And if you add a new third-party SDK that’s on the list of commonly used third-party SDKs, these API, privacy manifest, and signature requirements will apply to that SDK.”
"Make sure to use a version of the SDK that includes its privacy manifest and note that signatures are also required when the SDK is added as a binary dependency."
There is a description above. Our app uses the SDK (Alamofire) listed in the list, and a new version that is compatible with the Privacy Manifest has been released, but the SDK signature has not yet been completed. The embedded methods provided by Alamofire (CocoaPods and Carthage) are downloaded in a binary-dependent format and are therefore subject to the above requirements.
■Matters you should check
If this continues, there is a risk that when we release our app after May 1st, it will be rejected because the SDK signature has not been applied. Currently, there is no indication that Alamofire will support this, so we understand that the requirements can be met by signing and releasing the code using the codesign command on our side. Am I correct in my understanding? Furthermore, since Alamofire is licensed by MIT, developers can modify it, so any developer can sign it.
We look forward to hearing from you.