Any support/plan of Privacy Manifest?
Angus-chang opened this issue ยท 119 comments
Following the same topic in RxSwift offical slack. According to the definition of "third-party SDKs" that as mentioned in the WWDC23, new documents: Privacy manifest files | Apple Developer Documentation and the new announcement from Apple. It seems like RxSwift/RxCocoa/RxRelay require a privacy manifest and signature as well.
I was wondering if the Privacy Manifest update will be introduce in following updates, and, whether it is possible for us to know the schedule so that we can plan and manage our app releases more effectively.. Deeply appreciated.
Platform/Environment
- iOS
- macOS
- tvOS
- watchOS
- playgrounds
Installation method:
- CocoaPods
- Carthage
- Git submodules
Level of RxSwift knowledge:
(this is so we can understand your level of knowledge
and formulate the response in an appropriate manner)
- just starting
- I have a small code base
- I have a significant code base
+1
+1
Agree that this needs to be added, there are still a lot of apps using RxSwift I think.
Definitely something we'll add by the deadline. There's almost a year by then. Thanks!
If one of you who has already looked into this could add it, that would be fantastic. If you have any questions about the library itself. Reach out to me on Slack.
Yeah, actually if anyone wants to open a relevant PR that would help immensely ๐ thanks!
Here's an example, even though RxSwift doesn't track anything or does any API calls on its own, so there's really no privacy content to describe: https://github.com/BranchMetrics/ios-branch-sdk-spm/blob/main/BranchSDK/PrivacyInfo.xcprivacy
I simply looked it up, and it seems like 'mach_absolute_time' is used, did I make a mistake?
I simply looked it up, and it seems like 'mach_absolute_time' is used, did I make a mistake?
Might be missing something but what's the privacy concern with mach time ?
I was just looking up the API list in the Apple document in the RxSwift project.
The way I did it is as follows.
- Clone the RxSwift project to my computer
- I opened the project using Xcode.
- Through the entire search, the API was searched one by one.
(If the above method is wrong, please let me know.)
I checked and found that 'mach_absolute_time' exists in the 'Tests' folder, isn't this a problem??
Not a problem. It just needs a reason for being there.
The RxSwift tests harness uses
mach_absolute_time()in order to test performance only; it is not used in the production code and is not sent off device.
Here's an example, even though RxSwift doesn't track anything or does any API calls on its own, so there's really no privacy content to describe:
Oh, I'm afraid I didn't say it correctly. It's my mistake to say "problem."
(I am not good at English.)
I mean... @freak4pc said 'so there's really no privacy content to description', shouldn't we write down the description in PrivacyInfo if RxSwift use 'mach_absolute_time'??
Yes, the description needs to be added to the privacy info. I provided you the description above.
if mach_absolute_time() is the only API that is used in the project, mentioned by @wlxo0401, I think we just need to declare the use of the API and its purpose in the privacy file, as mentioned by Apple. then it should work?
For reference, this is a PR of Kingfisher, adding privacy manifest to the project:
onevcat/Kingfisher#2156
I can try to work on this on the 1st week of 2024, if anyone is free to work it out these days, feel free to create a PR.
Apple specifically mentioned RxSwift, but within the RxSwift ecosystem, there are various related libraries like RxCocoa, RxRelay, RxBlocking, RxTest, and RxSwift-Dynamic, among others.
(And we can only choose what we want.)
The question is whether you should include PrivacyInfo documentation for each of these libraries separately or if a single PrivacyInfo entry is sufficient.
(Use Chat GPT for translation)
Apple specifically mentioned RxSwift, but within the RxSwift ecosystem, there are various related libraries like RxCocoa, RxRelay, RxBlocking, RxTest, and RxSwift-Dynamic, among others. (And we can only choose what we want.)
The question is whether you should include PrivacyInfo documentation for each of these libraries separately or if a single PrivacyInfo entry is sufficient.
(Use Chat GPT for translation)
According to the Apple's Article:
RxCocoa, RxRelay, RxSwift is on the list.
If that's the case, I think adding privacy files to these 3 libraries should do the job?
Thank you so much for your quick response.
I have another question about Privacy Manifest, not Rx content...
- If Apple does not mention the library, but there is something to record in 'PrivacyInfo'
- If Apple mentions it but there is nothing to record in 'PrivacyInfo'
- If Apple doesn't mention it and doesn't have anything to write in "PrivacyInfo"
What happens to each of the above situations?
As far as I know, Privacy Manifest is compulsory for third-party libraries, but when I look at other library communities, I'm confused because some places can't even be mentioned.
As far as I know, Privacy Manifest is compulsory for third-party libraries, but when I look at other library communities, I'm confused because some places can't even be mentioned.
May I know the reference from Apple that Privacy Manifest is compulsory for 3rd party libraries?
If that's the case, then many old libraries in cocoapods may require updates, which may cause a massacre of the whole community.
According to my understanding, only the SDKs mentioned by Apple on the list are compulsory to add privacy manifests. Or else you cannot perform App Submissions.
From Fall 2023 youโll receive an email from Apple if you upload an app to App Store Connect that uses required reason API without describing the reason in its privacy manifest file. From Spring 2024, apps that donโt describe their use of required reason API in their privacy manifest file wonโt be accepted by App Store Connect.
It is part of the contents of the above document.
The contents that can be included in 'PrivacyInfo' are as follows.
[NSPrivacyTracking, NSPrivacyTrackingDomain, NSPrivacyCollectedDataType, NSPrivacyAccessAPType]
However, in the case of 'NSPrivacyAccessAPType', the document had the above contents.
I understood that, 'All third party libraries should add Privacy Manifest if they have a 'Describing use of required reason API'.
Did I get it too differently?
All third-party libraries should add a Privacy Manifest if they have a 'Describing use of required reason API'
Agree on this.
But I think Apple understands that a massacre will be summoned if they enforce all 3rd party libraries need to add Privacy Manifest lol. So that's why they provided a list of must-provide SDKs.
A bit off-topic. I will try to add a privacy manifest to the 3 repositories mentioned by Apple next week.
Please feel free to provide info related to this issue, thanks.
Seems @wlxo0401 has created a PR (as mentioned above), please feel free to take a look.
According to my understanding, only the SDKs mentioned by Apple on the list are compulsory to add privacy manifests. Or else you cannot perform App Submissions.
Actually, all libraries or SDK which use this functions Apple Doc have to add Privacy Manifest, Apple just mentioned few of them which are common libraries, so all SDK developers should review their own SDK whether they are mentioned by Apple or not. CMIIW
According to my understanding, only the SDKs mentioned by Apple on the list are compulsory to add privacy manifests. Or else you cannot perform App Submissions.
Actually, all libraries or SDK which use this functions Apple Doc have to add Privacy Manifest, Apple just mentioned a few of them which are common libraries, so all SDK developers should review their own SDK whether they are mentioned by Apple or not. CMIIW
Agree on this.
But then Apple announced a list(on early December 2023) of libraries/SDK that need to add privacyInfo, or else the app cannot submitted to app store. That's why I used the word compulsory in the statement.
Clarify one thing is, I agree that eventually all 3rd party SDK may need to add the file. I just worried about the long-term ongoing progress of the review process.
Thanks for the info @lambda123254! Much appreciated.
I discovered a new while testing.
Until now, most of the libraries that have added PrivacyInfo have not been marked in PrivacyReport.
However, when an item is added to the 'Privacy Nutrition Label Types', the library name is displayed in the PrivacyReport.
Many libraries have updated PrivacyInfo without adding anything from 'Privacy Nutrition Label Types'.
Does anyone know about this? Is 'Privacy Nutrition Label Types' a must-have item?
Or is it not necessary to display it in the privacy report?
Please feel free to leave opinion.
(I used a translator.)
I guess this is something from HealthKit, where this type of info should treated properly?
I guess this is something from HealthKit, where this type of info should treated properly?
I didn't use HealthKit.
The comment I posted seems to have a translation error, so I corrected it again.๐ญ
I discovered a new while testing.
Until now, most of the libraries that have added PrivacyInfo have not been marked in PrivacyReport.
However, when an item is added to the 'Privacy Nutrition Label Types', the library name is displayed in the PrivacyReport.
Many libraries have updated PrivacyInfo without adding anything from 'Privacy Nutrition Label Types'.
Does anyone know about this? Is 'Privacy Nutrition Label Types' a must-have item?
Or is it not necessary to display it in the privacy report?
Please feel free to leave opinion.
(I used a translator.)
May I know wdym by PrivacyReport? Thanks.
May I know wdym by PrivacyReport? Thanks.
The 'PrivacyReport' I'm talking about can be downloaded as a PDF if you archive the app.
https://developer.apple.com/videos/play/wwdc2023/10060/
Please refer to 3:20.
-
Open your project in Xcode.
-
Choose Product > Archive. Xcode creates the archive and reveals it in the organizer.
-
Control-click the archive in the organizer and choose Generate Privacy Report.
May I know wdym by PrivacyReport? Thanks.
The 'PrivacyReport' I'm talking about can be downloaded as a PDF if you archive the app.
https://developer.apple.com/videos/play/wwdc2023/10060/ Please refer to 3:20.
- Open your project in Xcode.
- Choose Product > Archive. Xcode creates the archive and reveals it in the organizer.
- Control-click the archive in the organizer and choose Generate Privacy Report.
Understand, could you provide a sample project which can reproduce this condition? That could help on the investigation.
The privacy report is organized in a similar way to Privacy Nutrition Labels.
I think what you mean is something here:
reference
I am just guessing the privacy labels can only be seen when you upload the app to the app store connect page, and let them help you make the thing.
@tommyming
Um... I'm sorry. I think I asked a question without really understanding 'PrivacyRport' and 'Privacy Nutrition Label Types'. Let me find out again.๐ฅ
@tommyming Um... I'm sorry. I think I asked a question without really understanding 'PrivacyRport' and 'Privacy Nutrition Label Types'. Let me find out again.๐ฅ
Huge thanks to @wlxo0401 for putting together #2572, it's very much appreciated ๐ I've worked with Privacy Manifests a fair bit, and I'd be very surprised if any of the Rx repos were accessing any of the data on this list. There's maybe a tiny chance that they're accessing data in the Identifiers and/or Diagnostics categories- but again, that sounds very unlikely. Anything I might be overlooking @freak4pc @danielt1263?
Following the same topic in RxSwift offical slack. According to the definition of "third-party SDKs" that as mentioned in the WWDC23, new documents: Privacy manifest files | Apple Developer Documentation and the new announcement from Apple. It seems like RxSwift/RxCocoa/RxRelay require a privacy manifest and signature as well.
I was wondering if the Privacy Manifest update will be introduce in following updates, and, whether it is possible for us to know the schedule so that we can plan and manage our app releases more effectively.. Deeply appreciated.
Platform/Environment
iOS
macOS
tvOS
watchOS
playgrounds
Installation method:
CocoaPods
Carthage
Git submodules
Level of RxSwift knowledge:
(this is so we can understand your level of knowledge
and formulate the response in an appropriate manner)
just starting
I have a small code base
I have a significant code base
Folks, I appreciate the research being done in this thread, could someone please shed a light on why RxSwift (or any other Rx* module for that matter) needs a privacy manifest, if mach_absolute_time is only used in tests, i.e. code that's not deployed to users?
... could someone please shed a light on why RxSwift (or any other Rx* module for that matter) needs a privacy manifest, if
mach_absolute_timeis only used in tests, i.e. code that's not deployed to users?
Because some automated tool at Apple went over the RxSwift library and flag its use.
Hi all, is there a timeline for when we can expect this to be completed? According to Apple's documentation: Upcoming third-party SDK requirements, the deadline is spring 2024.
I see there's a PR up: #2572. Is there anything we can do to finish what's left so that it can be merged? Thank you.
Hi all, is there a timeline for when we can expect this to be completed? According to Apple's documentation: Upcoming third-party SDK requirements, the deadline is spring 2024. I see there's a PR up: #2572. Is there anything we can do to finish what's left so that it can be merged? Thank you.
+1
Apple just announced the exact timelines for this: warning emails are starting on March 13, and app rejections will start on May 1.
Could one of the project maintainers review and hopefully merge #2572 soon? @danielt1263 Is that something you're able to do?
Not me... As far as I know only @freak4pc can do this.
Hey all,
I commented on the opened PR - the mach_absolute_time API is irrelevant to consumers of this SDK, it's only in our own tests so the privacy manifest shouldn't be relevant here. If it is still required by Apple, it won't have anything to report from a privacy perspective.
See note here:
#2572 (review)
Hey all,
I commented on the opened PR - the mach_absolute_time API is irrelevant to consumers of this SDK, it's only in our own tests so the privacy manifest shouldn't be relevant here. If it is still required by Apple, it won't have anything to report from a privacy perspective.
See note here: #2572 (review)
Hi @freak4pc,
I understand your point, but that's irrelevant. Ultimately, Apple has mandated that RxCocoa, RxRelay, and RxSwift, all need to include privacy manifest and signature. They're specifically called out in Upcoming third-party SDK requirements.
It's totally reasonable to include a manifest to declare that they're not using any of the affected APIs or track anything. However, they must include such file regardless. Otherwise, it can be a reason for rejection when the rule comes into effect. It will be really unfortunate if we have to fork the repos just to add this manifest to avoid being rejected by Apple. This is why many of us have been asking for progress.
Thank you.
Hey all,
I commented on the opened PR - the mach_absolute_time API is irrelevant to consumers of this SDK, it's only in our own tests so the privacy manifest shouldn't be relevant here. If it is still required by Apple, it won't have anything to report from a privacy perspective.
See note here: #2572 (review)Hi @freak4pc,
I understand your point, but that's irrelevant. Ultimately, Apple has mandated that RxCocoa, RxRelay, and RxSwift, all need to include privacy manifest and signature. They're specifically called out in Upcoming third-party SDK requirements.
It's totally reasonable to include a manifest to declare that they're not using any of the affected APIs or track anything. However, they must include such file regardless. Otherwise, it can be a reason for rejection when the rule comes into effect. It will be really unfortunate if we have to fork the repos just to add this manifest to avoid being rejected by Apple. This is why many of us have been asking for progress.
Thank you.
I'm a bit confused by your response and number of likes. I didn't say we shouldn't add it, I said that the fact they're asking it is based on a mistake, and if we provide it, that manifest should be empty since we have nothing to report. We can continue the discussion in the other thread.
Hello all,
I saw there's a PR in progress, is there any support for code signing?
Hey all,
I commented on the opened PR - the mach_absolute_time API is irrelevant to consumers of this SDK, it's only in our own tests so the privacy manifest shouldn't be relevant here. If it is still required by Apple, it won't have anything to report from a privacy perspective.
See note here: #2572 (review)Hi @freak4pc,
I understand your point, but that's irrelevant. Ultimately, Apple has mandated that RxCocoa, RxRelay, and RxSwift, all need to include privacy manifest and signature. They're specifically called out in Upcoming third-party SDK requirements.
It's totally reasonable to include a manifest to declare that they're not using any of the affected APIs or track anything. However, they must include such file regardless. Otherwise, it can be a reason for rejection when the rule comes into effect. It will be really unfortunate if we have to fork the repos just to add this manifest to avoid being rejected by Apple. This is why many of us have been asking for progress.
Thank you.I'm a bit confused by your response and number of likes. I didn't say we shouldn't add it, I said that the fact they're asking it is based on a mistake, and if we provide it, that manifest should be empty since we have nothing to report. We can continue the discussion in the other thread.
The way we can check right away is to review apps that have applied 'Privacy Manifest' without any new updates of the app from March 13th.
Through this, we can check Apple's response.
So I'm going to use 'Manually Release' to do a repetitive test in a way that even if I pass the examination, I'm going to cancel it.
If a lot of people's information is gathered, won't we find a sure way within May??
Hey there,
Our own app (monday.com) will be in review in a few days and I can't believe it will be rejected over this. This seems like an entire mistake on Apple's end. For example, AFNetworking is also in that list and it's been in Archived state for a while now.
I've opened a TSI to Apple Engineering and hoping to hear back from them soon, but I'm 99% we won't be experiencing any problems since RxSwift (and child libraries) don't use any of the privacy-related APIs outlined in Apple's docs.
Let's examine over the next few days. It isn't difficult adding an empty xcprivacy file but Apple recommends not doing that, and we have nothing to report from the framework's side.
Hey there, Our own app (monday.com) will be in review in a few days and I can't believe it will be rejected over this. This seems like an entire mistake on Apple's end. For example, AFNetworking is also in that list and it's been in Archived state for a while now.
I've opened a TSI to Apple Engineering and hoping to hear back from them soon, but I'm 99% we won't be experiencing any problems since RxSwift (and child libraries) don't use any of the privacy-related APIs outlined in Apple's docs.
Let's examine over the next few days. It isn't difficult adding an empty xcprivacy file but Apple recommends not doing that, and we have nothing to report from the framework's side.
Do you recall where Apple recommend not adding an empty one?
Snapkit was also called out but has added an empty one here: https://github.com/SnapKit/SnapKit/blob/develop/Sources/PrivacyInfo.xcprivacy
It would seem if the SDK is specifically listed on Apple's documentation list then it would need a manifest whether or not it has anything to report using, right?
Let's examine over the next few days. It isn't difficult adding an empty xcprivacy file but Apple recommends not doing that, and we have nothing to report from the framework's side.
Do you have any update for this?
We've get ITMS-91053: Missing API declaration warning now.
Thanks for the reply. This was caused by Apple's tool not detecting the privacy manifest of the Firebase SDK.
Let's examine over the next few days. It isn't difficult adding an empty xcprivacy file but Apple recommends not doing that, and we have nothing to report from the framework's side.
Do yot have any update for this?
We've get ITMS-91053: Missing API declaration warning now.
We didn't get it for RxSwift.
Can you share the warnings you got?
@freak4pc Did you receive any warnings at all when you submitted your app? Note that uploading a TestFlight build won't trigger the email; you have to actually submit it for review (which is crazy I know). If you or anyone submits a build for review that includes RxSwift, and don't receive a warning email, that would go a long way towards proving the hypothesis that RxCocoa/RxRelay/RxSwift don't need a privacy manifest.
For reference here's the warning we received in our app; because it's so vague, it's impossible to tell if it was caused by RxSwift, Firebase, or something else.
ITMS-91053: Missing API declaration - Your appโs code in the โAspirationโ file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryFileTimestamp. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your appโs privacy manifest to provide approved reasons for these APIs used by your appโs code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api.
@jpeckner Apple has a list of all the function calls/properties that will require a NSPrivacyAccessedAPICategoryFileTimestamp. The RxSwift library doesn't use any of them. Your problem is likely elsewhere.
@freak4pc Did you receive any warnings at all when you submitted your app? Note that uploading a TestFlight build won't trigger the email; you have to actually submit it for review (which is crazy I know). If you or anyone submits a build for review that includes RxSwift, and don't receive a warning email, that would go a long way towards proving the hypothesis that RxCocoa/RxRelay/RxSwift don't need a privacy manifest.
For reference here's the warning we received in our app; because it's so vague, it's impossible to tell if it was caused by RxSwift, Firebase, or something else.
ITMS-91053: Missing API declaration - Your appโs code in the โAspirationโ file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryFileTimestamp. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your appโs privacy manifest to provide approved reasons for these APIs used by your appโs code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api.
We didn't get any timestamp warnings, I got other warnings but their inside out own code base, not RxSwift (we're fixing them)
@freak4pc Thanks! Sounds like we can probably rule-out RxSwift as a cause of the NSPrivacyAccessedAPICategoryFileTimestamp warning. Just so we all know for sure, appreciate if you or anyone else could post here when you've successfully submitted a build with RxSwift that doesn't get any warnings (I'll do the same if I get there too).
we got similar warning but this could be due to Firebase SDK
So I guess if there are more cases in which RxSwift have no issues,
the PR from me and @wlxo0401 is unnecessary?
That's good if no privacy manifest is needed for this repo!
Many thanks for the effort for everyone in this thread.
@tommyming I'm not sure that we can be sure yet ๐ I'm currently using process-of-elimination where I submit builds that intentionally omit SDKs on Apple's list (such as Firebase), see what warnings we get, then immediately cancel the submission. Still a WIP, but haven't definitively established yet that RxSwift is exempt from a privacy manifest. So I wouldn't delete the PR just yet.
As I was conducting the test, I thought it wasn't like inspecting each individual's library.
Test was conducted with a different library.
-
If deploy a new build externally via Test Flight, Can receive mail.(If there is a problem)
-
If that's a problem, adding the Privacy Type to the app's 'PrivacyInfo' will fix the problem. (Same with the static library (.a))
-
If there is a type that needs to be entered, I guess can create a 'Privacy Manifest' to inform third parties or help them add it to the app's 'PrivacyInfo' by notifying them separately.
-
If it is used for internal purposes or there is no content even if it is shared with a third party, there seems to be no need to add 'Privacy Manifest'.
-
Apple has separately distinguished an commonly used SDKs(like rxswift, alamofire), but it doesn't seem to be inspecting this.
That's my guess.
Please let me know if my test is wrong.
Please feel free to share your opinion.
Do you recall where Apple recommend not adding an empty one?
Snapkit was also called out but has added an empty one here: https://github.com/SnapKit/SnapKit/blob/develop/Sources/PrivacyInfo.xcprivacy
It would seem if the SDK is specifically listed on Apple's documentation list then it would need a manifest whether or not it has anything to report using, right?
@mitchins
https://developer.apple.com/forums/thread/746481?answerId=782256022#782256022
If that's a problem, adding the Privacy Type to the app's 'PrivacyInfo' will fix the problem. (Same with the static library (.a))
If there is a type that needs to be entered, I guess can create a 'Privacy Manifest' to inform third parties or help them add it to the app's 'PrivacyInfo' by notifying them separately.
If it is used for internal purposes or there is no content even if it is shared with a third party, there seems to be no need to add 'Privacy Manifest'.
Apple has separately distinguished an commonly used SDKs(like rxswift, alamofire), but it doesn't seem to be inspecting this.
I have got the same results for the 1st and 2nd case you mentioned.
The main problem is the 3rd and 4th case, which the 4th is also the main issue of RxSwift.
For the "internal use"(4th) case, I am still investigating my app after several attempts uploaded it to App Store.
But I can't find mach_absolute_time(API used in RxSwift) in the warnings. Mainly are warnings from other libraries.
For the 3rd case, I think we need to know the use-case of the privacy type in the third-party first, then determine if it is necessary to add PrivacyInfo or not.
According to my understanding, only the SDKs mentioned by Apple on the list are compulsory to add privacy manifests. Or else you cannot perform App Submissions.
Actually, all libraries or SDK which use this functions Apple Doc have to add Privacy Manifest, Apple just mentioned few of them which are common libraries, so all SDK developers should review their own SDK whether they are mentioned by Apple or not. CMIIW
Hello, I think so too. However, I couldn't find any documents on Apple's official website that formally support my idea. Have you found any documents related to this idea?
Hey all,
I commented on the opened PR - the mach_absolute_time API is irrelevant to consumers of this SDK, it's only in our own tests so the privacy manifest shouldn't be relevant here. If it is still required by Apple, it won't have anything to report from a privacy perspective.
See note here: #2572 (review)Hi @freak4pc,
I understand your point, but that's irrelevant. Ultimately, Apple has mandated that RxCocoa, RxRelay, and RxSwift, all need to include privacy manifest and signature. They're specifically called out in Upcoming third-party SDK requirements.
It's totally reasonable to include a manifest to declare that they're not using any of the affected APIs or track anything. However, they must include such file regardless. Otherwise, it can be a reason for rejection when the rule comes into effect. It will be really unfortunate if we have to fork the repos just to add this manifest to avoid being rejected by Apple. This is why many of us have been asking for progress.
Thank you.I'm a bit confused by your response and number of likes. I didn't say we shouldn't add it, I said that the fact they're asking it is based on a mistake, and if we provide it, that manifest should be empty since we have nothing to report. We can continue the discussion in the other thread.
Hello, I understand your point, but I'm still interested in knowing a rough timeline regarding the decision on how to address PrivacyInfo, as I need to report back to the company.
For the company, it's clear that taking any risk that might lead to the app being rejected upon submission is undesirable. Therefore, based on Apple's current statements, no matter what the outcome of the app submission testing process is, PrivacyInfo should be incorporated to avoid the risk of app rejection, unless Apple issues a new statement to explain this situation.
Hey there!
I thought the discussion was pretty clear but I'll outline the decision and what we know so far:
- The list Apple published isn't based on any API scan. It takes 5 minutes of going through these repositories to see that a good chunk of them don't use any privacy-related APIs.
- Since then Apple has released an official document with rules as to what needs a privacy manifest.
- We might need to provide signing for the project for new apps, but I do not see a reasoning for a privacy manifest at the moment.
- When digging into RxSwift's own open code base, you'll find that we don't use any of the privacy related APIs Apple published in their official documentation
- In the Apple forums, as indicated by a DTS engineer, it is recommended not adding an empty privacy manifest for no reason.
- We've reached out to Apple DTS and are waiting an official response. Currently I do not see any reason to add an empty manifest based on the recommendations.
- Our own apps have been through review with no issues so far.
If that's a problem, adding the Privacy Type to the app's 'PrivacyInfo' will fix the problem. (Same with the static library (.a))
If there is a type that needs to be entered, I guess can create a 'Privacy Manifest' to inform third parties or help them add it to the app's 'PrivacyInfo' by notifying them separately.
If it is used for internal purposes or there is no content even if it is shared with a third party, there seems to be no need to add 'Privacy Manifest'.
Apple has separately distinguished an commonly used SDKs(like rxswift, alamofire), but it doesn't seem to be inspecting this.I have got the same results for the 1st and 2nd case you mentioned. The main problem is the 3rd and 4th case, which the 4th is also the main issue of RxSwift.
For the "internal use"(4th) case, I am still investigating my app after several attempts uploaded it to App Store. But I can't find (API used in RxSwift) in the warnings. Mainly are warnings from other libraries.
mach_absolute_timeFor the 3rd case, I think we need to know the use-case of the privacy type in the third-party first, then determine if it is necessary to add or not.
PrivacyInfo
I thought it might be misleading, so I added a number to the post I left. Did it match the same number you said??
Hey there! I thought the discussion was pretty clear but I'll outline the decision and what we know so far:
- The list Apple published isn't based on any API scan. It takes 5 minutes of going through these repositories to see that a good chunk of them don't use any privacy-related APIs.
- Since then Apple has released an official document with rules as to what needs a privacy manifest.
- When digging into RxSwift's own open code base, you'll find that we don't use any of the privacy related APIs Apple published in their official documentation
- In the Apple forums, as indicated by a DTS engineer, it is recommended not adding an empty privacy manifest for no reason.
- We've reached out to Apple DTS and are waiting an official response. Currently I do not see any reason to add an empty manifest based on the recommendations.
- Our own apps have been through review with no issues so far.
what about apple's requirements list? https://developer.apple.com/support/third-party-SDK-requirements/
Hey there! I thought the discussion was pretty clear but I'll outline the decision and what we know so far:
- The list Apple published isn't based on any API scan. It takes 5 minutes of going through these repositories to see that a good chunk of them don't use any privacy-related APIs.
- Since then Apple has released an official document with rules as to what needs a privacy manifest.
- When digging into RxSwift's own open code base, you'll find that we don't use any of the privacy related APIs Apple published in their official documentation
- In the Apple forums, as indicated by a DTS engineer, it is recommended not adding an empty privacy manifest for no reason.
- We've reached out to Apple DTS and are waiting an official response. Currently I do not see any reason to add an empty manifest based on the recommendations.
- Our own apps have been through review with no issues so far.
what about apple's requirements list? https://developer.apple.com/support/third-party-SDK-requirements/
Without an official answer from DTS, we don't have a clear understanding of why we're on that list to begin with. There are too many conflicting guidelines for us to do anything and for now that means we're on hold until there are clear requirements.
There's a script you can use to scan your project for the Required reason APIs: https://github.com/Wooder/ios_17_required_reason_api_scanner
We're using RxSwift/RxCocoa/RxRelay (v6.5.0) and that script didn't find any usage of those APIs.
There's a script you can use to scan your project for the Required reason APIs: https://github.com/Wooder/ios_17_required_reason_api_scanner
We're using RxSwift/RxCocoa/RxRelay (v6.5.0) and that script didn't find any usage of those APIs.
nice! lfg...
If that's a problem, adding the Privacy Type to the app's 'PrivacyInfo' will fix the problem. (Same with the static library (.a))
If there is a type that needs to be entered, I guess can create a 'Privacy Manifest' to inform third parties or help them add it to the app's 'PrivacyInfo' by notifying them separately.
If it is used for internal purposes or there is no content even if it is shared with a third party, there seems to be no need to add 'Privacy Manifest'.
Apple has separately distinguished an commonly used SDKs(like rxswift, alamofire), but it doesn't seem to be inspecting this.I have got the same results for the 1st and 2nd case you mentioned. The main problem is the 3rd and 4th case, which the 4th is also the main issue of RxSwift.
For the "internal use"(4th) case, I am still investigating my app after several attempts uploaded it to App Store. But I can't find (API used in RxSwift) in the warnings. Mainly are warnings from other libraries.mach_absolute_time
For the 3rd case, I think we need to know the use-case of the privacy type in the third-party first, then determine if it is necessary to add or not.PrivacyInfoI thought it might be misleading, so I added a number to the post I left. Did it match the same number you said??
@wlxo0401
Yes, it matched. Thanks for adding them in. I have no comment on point 5.
Hey there! I thought the discussion was pretty clear but I'll outline the decision and what we know so far:
- The list Apple published isn't based on any API scan. It takes 5 minutes of going through these repositories to see that a good chunk of them don't use any privacy-related APIs.
- Since then Apple has released an official document with rules as to what needs a privacy manifest.
- When digging into RxSwift's own open code base, you'll find that we don't use any of the privacy related APIs Apple published in their official documentation
- In the Apple forums, as indicated by a DTS engineer, it is recommended not adding an empty privacy manifest for no reason.
- We've reached out to Apple DTS and are waiting an official response. Currently I do not see any reason to add an empty manifest based on the recommendations.
- Our own apps have been through review with no issues so far.
what about apple's requirements list? https://developer.apple.com/support/third-party-SDK-requirements/
Without an official answer from DTS, we don't have a clear understanding of why we're on that list to begin with. There are too many conflicting guidelines for us to do anything and for now that means we're on hold until there are clear requirements.
hi, focus cocoapods, you can use https://github.com/ymoyao/cocoapods-privacy to scan and auto manager privacy apis, cocoapods-privacy plugin will crate a empty PrivacyInfo.xcprivacy file if none privacy api
I'll add that Apple added a deadline for May 1st, alluding that apps including SDKs in the "list of commonly used third-party SDKs" won't be able to update if they don't include the manifest and signature requirements.
Just dropping here for a reference to put some ease, to mind of existing applications' programmers.
I want to add this link where RxSwift is on the list and specifically this text section.
https://developer.apple.com/support/third-party-SDK-requirements/
SDKs that require a privacy manifest and signature
The following are commonly used SDKs in apps on the App Store. Starting in spring 2024, you must include the privacy manifest for any SDK listed below when you submit new apps in App Store Connect that include those SDKs, or when you submit an app update that adds one of the listed SDKs as part of the update. Signatures are also required in these cases where the listed SDKs are used as binary dependencies. Any version of a listed SDK, as well as any SDKs that repackage those on the list, are included in the requirement.
Please notice how if you upload existing apps, it won't be a problem but if you upload a new app using RxSwift then that might be a problem according to the video @rptwsthi also linked.
I apologize for the inconvenience, but I would like to confirm the following.
(1) >> #2567 (comment)
Among the libraries specified by Apple, if the following conditions apply, it is recognized that privacy manifest compliance is required, and if it is an update of an existing application, is it okay to recognize that there is no particular problem?
ใปWhen using the specified library (RxSwift) in a new application
ใปWhen extending the functionality of an existing app using a new specified library (RxSwift)
(2) >> #2567 (comment)
Previously, it was said that AppleDTS had confirmed the response policy regarding RxSwift, but what is the response status?
(3) Since Rxswift is aware that Privacy Manifest is not supported (pending support), we are considering supporting it as an app-specific setting as an alternative method.
Regarding the above response, there are some things you would like to check below.
ใปDo you have a definition of the data to be collected?
ใปIs there a definition for the Required Reason API? If so, what is its purpose?
ใปDo you have a tracking domain defined? If so, what are the detailed settings?
We apologize for any inconvenience this may cause and would be happy if you could give us an answer.
I want to add this link where RxSwift is on the list and specifically this text section. https://developer.apple.com/support/third-party-SDK-requirements/
SDKs that require a privacy manifest and signature The following are commonly used SDKs in apps on the App Store. Starting in spring 2024, you must include the privacy manifest for any SDK listed below when you submit new apps in App Store Connect that include those SDKs, or when you submit an app update that adds one of the listed SDKs as part of the update. Signatures are also required in these cases where the listed SDKs are used as binary dependencies. Any version of a listed SDK, as well as any SDKs that repackage those on the list, are included in the requirement.
Please notice how if you upload existing apps, it won't be a problem but if you upload a new app using RxSwift then that might be a problem according to the video @rptwsthi also linked.
We did not find sufficient reasoning to have a privacy manifest since we're not using any of the APIs. We're still awaiting response from Apple on this (like other framework vendors) but they are not very responsive as you can imagine.
In regards to SDK signatures, we'll probably want to add it regardless. We'll be happy for a PR to push this forward if anyone's interested in contributing!
I understand that everyone wants to apply a privacy manifest.
But we have something to check here.
- Apple once told not to add empty 'Privacy Manifest' in developer forum comments.
- RxSwift belongs to the 'commonly used SDKs' mentioned by Apple.
We need to check.
Apple said it would give you an e-mail if there was a problem, and it specifies what the problem was.
However, there is currently no email related to RxSwift other than API usage.
And it's not hard to add 'PrivacyInfo'.
Even if Apple replies, "Add 'PrivacyInfo' to RxSwift," I think this would be a principled answer.
(It's my personal opinion because there's so much vague about what Apple currently claims and what's in the document and the actual test results.)
I think we need to wait and check.
In my opinion we need to wait, don't worry as it's not like @freak4pc not responding. For those who are really in a hurry, you can Fork to add 'PrivateManifest' and watch the Apple response.
I understand that everyone wants to apply a privacy manifest.
But we have something to check here.
- Apple once told not to add empty 'Privacy Manifest' in developer forum comments.
- RxSwift belongs to the 'commonly used SDKs' mentioned by Apple.
We need to check.
Apple said it would give you an e-mail if there was a problem, and it specifies what the problem was.
However, there is currently no email related to RxSwift other than API usage.
And it's not hard to add 'PrivacyInfo'.
Even if Apple replies, "Add 'PrivacyInfo' to RxSwift," I think this would be a principled answer. (It's my personal opinion because there's so much vague about what Apple currently claims and what's in the document and the actual test results.)
I think we need to wait and check.
In my opinion we need to wait, don't worry as it's not like @freak4pc not responding. For those who are really in a hurry, you can Fork to add 'PrivateManifest' and watch the Apple response.
Thanks for the reply @freak4pc @wlxo0401.
I think apart from workarounds, maybe others can share more about the results from App Store when you include RxSwift as a dependency, after submitting the app for review?
Suppose there should be warnings from App Store Connect right now, in case any problems from Privacy Manifest.
I understand that everyone wants to apply a privacy manifest.
But we have something to check here.
- Apple once told not to add empty 'Privacy Manifest' in developer forum comments.
- RxSwift belongs to the 'commonly used SDKs' mentioned by Apple.
We need to check.
Apple said it would give you an e-mail if there was a problem, and it specifies what the problem was.
However, there is currently no email related to RxSwift other than API usage.
And it's not hard to add 'PrivacyInfo'.
Even if Apple replies, "Add 'PrivacyInfo' to RxSwift," I think this would be a principled answer. (It's my personal opinion because there's so much vague about what Apple currently claims and what's in the document and the actual test results.)
I think we need to wait and check.
In my opinion we need to wait, don't worry as it's not like @freak4pc not responding. For those who are really in a hurry, you can Fork to add 'PrivateManifest' and watch the Apple response.Thanks for the reply @freak4pc @wlxo0401.
I think apart from workarounds, maybe others can share more about the results from App Store when you include RxSwift as a dependency, after submitting the app for review?
Suppose there should be warnings from App Store Connect right now, in case any problems from Privacy Manifest.
I personally had no warnings (only from my own app, Firebase and Sentry).
@wlxo0401 If apple provides a hard-cut answer "RxSwift should do this and it should be empty", we'll be happy to add it. Otherwise I currently don't see a reason to do so blindly.
@freak4pc Can I confirm the app you submitted that had Firebase + Sentry also included RxSwift and you got 0 warning from app store connect after submission?
@freak4pc Can I confirm the app you submitted that had Firebase + Sentry also included RxSwift and you got 0 warning from app store connect after submission?
Yup. Apple's talks specifically about entirely new apps to the app store.
SDKs that require a privacy manifest and signature
The following are commonly used SDKs in apps on the App Store. Starting in spring 2024, you must include the privacy manifest for any SDK listed below when you submit new apps in App Store Connect that include those SDKs, or when you submit an app update that adds one of the listed SDKs as part of the update. Signatures are also required in these cases where the listed SDKs are used as binary dependencies. Any version of a listed SDK, as well as any SDKs that repackage those on the list, are included in the requirement.
@freak4pc Thanks for confirming.
Quick thought, do you reckon Apple here is trying to get the listed SDKs add the collected data types aka privacy nutrition label to the manifest? Since RxSwift doesn't uses any of the required reason APIs, maybe Apple is just after the data collection usage?
Third-party SDKs need to provide their own privacy manifest files that record the types of data they collect.
As far as I can tell, Apple likely ran a tool over several libraries to make that initial list where RxSwift is mentioned. Since the RxSwift repository does use a method called out as requiring a privacy manifest, we were put on the list. What the tool didn't catch is that it's only the test harness uses the method, not in the API itself. So if a tool analyzes the entire RxSwift repo, it will flag, but if it only analyzes the code that is imported into other apps, it will not.
However, I am not an Apple employee and this is not an official Apple explanation. We are still waiting for Apple to resolve the conflicting advice they have given.
Just to stir the muddy water a bit: Apple, contrary to their own suggestion, apparently added an empty manifest to one of their own libraries, swift-crypto.
Just to stir the muddy water a bit: Apple, contrary to their own suggestion, apparently added an empty manifest to one of their own libraries, swift-crypto.
But also: apple/swift-crypto#225 (comment)
Any updates on Apple's side if it's needed or not?
Just to stir the muddy water a bit: Apple, contrary to their own suggestion, apparently added an empty manifest to one of their own libraries, swift-crypto.
But also: apple/swift-crypto#225 (comment)
Right, but since RxSwift was called out by name just like BoringSSL (and unlike swift-asn1 which the comment was about), doesn't that suggest that the empty manifest file should be added here as well?
Site a correction if I'm wrong, but a no point has Apple ever recommended putting an empty manifest file on any library.
I see a mention in this thread that we need a privacy manifest because of the use of mach_absolute_time() - ignoring for a moment whether RxSwift needs to provide a privacy manifest, I'm just wondering if the library itself need to provide a privacy manifest ?
Can't the privacy manifest be added to the main app itself that covers the reasons used by the library ? It would be different if the library installed as a binary and needed to be code signed, however, I don't think we install RxSwift as a binary ?
I see a mention in this thread that we need a privacy manifest because of the use of
mach_absolute_time()- ignoring for a moment whether RxSwift needs to provide a privacy manifest, I'm just wondering if the library itself need to provide a privacy manifest ?Can't the privacy manifest be added to the main app itself that covers the reasons used by the library ? It would be different if the library installed as a binary and needed to be code signed, however, I don't think we install RxSwift as a binary ?
@shawn-frank, It's difficult to answer this question with certainty.
I (like many of us) received the famous "TMS-91053: Missing API declaration" email from Apple after sending a build to AppStore (and TestFlight) Review.
I use this email as a sign that my build has or hasn't had the problem with "Required API".
So, I added a PrifacyInfo.xcprivacy manifest to my app, explaining all the "Required API Reasons".
After sending the build to the Apple Review I got no email with the warnings.
However, I keep in mind that while adding explanations for API usage can improve the chances of approval, it's not a guarantee. Apple's review process can be somewhat unpredictable, and they may have additional considerations beyond just the presence of the privacy manifest.
Does anyone can offer a tool to check if the added PrivacyInfo.xcprivacy file is right for the those problem' sdk and prj, I'm not sure if it will pass for AppStore Review, some one tolded me, he process those problem to review, but still received a email with warnings.
@linhaosunny The only "tool" that will work is AppStore Review. Apple has not provided a tool and also not given a detailed enough spec for anyone else to build a tool that can reliably detect for this requirement. My team has been test-sending things to TestFlight and when there's no privacy manifest, we get emails warning us, but when we include manifests we haven't gotten emails (but we don't know if that means the manifests fully meet the requirements or not because it's not after the May deadline yet where successful AppStore submission would tell us that affirmatively).
Thanks everyone for the discussion here and the clarifications. While I can see how we may interpret Apple's statement here about not applying to existing apps that use RxSwift, there still is the official documentation of the Privacy Manifest that does not make any of those additional clarifications.
Important
You need to include a privacy manifest file in your third-party SDK if itโs listed in โSDKs that require a privacy manifest and signature,โ in Upcoming third-party SDK requirements. Otherwise, include a privacy manifest file in your third-party SDK if it uses required reasons API, collects data about the person using apps that include the third-party SDK, enables the app to collect data about people using the app, or contacts tracking domains. Providing a privacy manifest file helps app developers to understand the API use and data-collection practices of your third-party SDK.
Is this changing anything on your opinion here? Cannot shrug off the feeling that we will run into issues with Apple . We did not clarifications from their side as well - I guess you also did not get any update from them?
@Ro-M The RxSwift SDK does not use any required reasons APIs, it does not collect data about the person using apps that include the SDK, it does not collect data about people using the app, and it does not contact tracking domains.
On the deadline in May, one of two things will happen:
- People will have approved App Store submissions and the RxSwift maintainers will say "I told you so", or
- People will have rejected App Store submissions due to RxSwift not having a manifest and everyone else will say "I told you so".
I do not understand why the RxSwift maintainers refuse to add an empty privacy manifest like ~all of the other libraries on Apple's list that don't use any Require Reasons APIs, but we'll all know for sure in a few weeks. I hope that it turns out to be 1 (where no one needs to do extra work), but if 2 happens, I hope RxSwift will add the manifest quickly.
Not sure if it's mentioned in this thread yet (I tried to look, but couldn't find any relevant comment),
but if mach_absolute_time only appears in Tests, then declaring a manifest within RxSwift would be fruitless because none of the "reasons" would be valid for RxSwift:
35F9.1
Declare this reason to access the system boot time in order to measure the amount of time that has elapsed between events that occurred within the app or to perform calculations to enable timers.
Information accessed for this reason, or any derived information, may not be sent off-device. There is an exception for information about the amount of time that has elapsed between events that occurred within the app, which may be sent off-device.
8FFB.1
Declare this reason to access the system boot time to calculate absolute timestamps for events that occurred within your app, such as events related to the [UIKit](https://developer.apple.com/documentation/uikit) or [AVFAudio](https://developer.apple.com/documentation/avfaudio) frameworks.
Absolute timestamps for events that occurred within your app may be sent off-device. System boot time accessed for this reason, or any other information derived from system boot time, may not be sent off-device.
3D61.1
Declare this reason to include system boot time information in an optional bug report that the person using the device chooses to submit. The system boot time information must be prominently displayed to the person as part of the report.
Information accessed for this reason, or any derived information, may be sent off-device only after the user affirmatively chooses to submit the specific bug report including system boot time information, and only for the purpose of investigating or responding to the bug report.
Note all of these are in the context of the app itself, i.e. the usage needs to be compiled into the app AND actually invoked as part of interaction with the app.
On the deadline in May, one of two things will happen:
- People will have approved App Store submissions and the RxSwift maintainers will say "I told you so", or
- People will have rejected App Store submissions due to RxSwift not having a manifest and everyone else will say "I told you so".
I do not understand why the RxSwift maintainers refuse to add an empty privacy manifest like ~all of the other libraries on Apple's list that don't use any Require Reasons APIs, but we'll all know for sure in a few weeks. I hope that it turns out to be 1 (where no one needs to do extra work), but if 2 happens, I hope RxSwift will add the manifest quickly.
We're not doing it because there is no legal or compliance reason for us to do so, and recommendations against doing it from DTS. If Opt. 2 happens for some reason we will immediately release a version with an empty manifest but I can mostly guarantee it shouldn't happen.
I remind you again that in any case this regulation only apps to entirely new app and not updates of existing apps that already use the dependencies listed there so it should not affect you in any way most likely.
If we will find issues with new apps (highly unlikely based on the writing in their documentation) we are happy to add it, but I prefer not adding it blindly for no reason.
I remind you again that in any case this regulation only apps to entirely new app and not updates of existing apps that already use the dependencies listed there so it should not affect you in any way most likely.
That's not true. People started receiving warnings from Apple for their apps updated from March 1st.
Just to clarify how it works:
Application developers tell users what API do they use it their apps through Privacy report. Privacy report is produced by merging all Privacy Manifests in the app bundle: main bundle manifest and all third-party dependencies manifests.
If a developer has an issue with Apple review, then you, as a maintainer of RxSwift, by bringing an empty but existing Privacy manifest, ensure developers that you are not the reason of the issue.
The only correct way for you to close this issue is to add empty Privacy Manifest to resources for each of your targets that do not use any API
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NSPrivacyTracking</key>
<false/>
<key>NSPrivacyAccessedAPITypes</key>
<array/>
<key>NSPrivacyCollectedDataTypes</key>
<array/>
<key>NSPrivacyTrackingDomains</key>
<array/>
</dict>
</plist>
If some of targets of use any APIs (eg RxTest), add a separate manifest describing them.
The only correct way for you to close this issue is to add empty Privacy Manifest to resources for each of your targets that do not use any API
In what Apple documentation did you read that every library ever written must create and include an empty manifest file? Do you have a source for this claim?
Note here that an Apple DTS Engineer says to "Avoid adding an empty privacy manifest to your framework."
I remind you again that in any case this regulation only apps to entirely new app and not updates of existing apps that already use the dependencies listed there so it should not affect you in any way most likely.
That's not true. People started receiving warnings from Apple for their apps updated from March 1st. Just to clarify how it works: Application developers tell users what API do they use it their apps through Privacy report. Privacy report is produced by merging all Privacy Manifests in the app bundle: main bundle manifest and all third-party dependencies manifests. If a developer has an issue with Apple review, then you, as a maintainer of RxSwift, by bringing an empty but existing Privacy manifest, ensure developers that you are not the reason of the issue. The only correct way for you to close this issue is to add empty Privacy Manifest to resources for each of your targets that do not use any API
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>NSPrivacyTracking</key> <false/> <key>NSPrivacyAccessedAPITypes</key> <array/> <key>NSPrivacyCollectedDataTypes</key> <array/> <key>NSPrivacyTrackingDomains</key> <array/> </dict> </plist>If some of targets of use any APIs (eg RxTest), add a separate manifest describing them.
Please read the entire thread, and don't write "you're wrong" without confirming your sources or bringing your own sources that support your claims: #2567 (comment)
- RxSwift doesn't require a privacy manifest because it makes no usage of any privacy-related APIs
- DTS mentioned several times like in the thread i linked that there is not reason to put an empty manifest if you don't make use of any relevant APIs.
- In the specific page where they outline RxSwift as a dependency that requires a manifest and signature, they are writing specifically:
"The following are commonly used SDKs in apps on the App Store. Starting in spring 2024, you must include the privacy manifest for any SDK listed below when you submit new apps in App Store Connect that include those SDKs, or when you submit an app update that adds one of the listed SDKs as part of the update."
On the deadline in May, one of two things will happen:
- People will have approved App Store submissions and the RxSwift maintainers will say "I told you so", or
- People will have rejected App Store submissions due to RxSwift not having a manifest and everyone else will say "I told you so".
I do not understand why the RxSwift maintainers refuse to add an empty privacy manifest like ~all of the other libraries on Apple's list that don't use any Require Reasons APIs, but we'll all know for sure in a few weeks. I hope that it turns out to be 1 (where no one needs to do extra work), but if 2 happens, I hope RxSwift will add the manifest quickly.
We're not doing it because there is no legal or compliance reason for us to do so, and recommendations against doing it from DTS. If Opt. 2 happens for some reason we will immediately release a version with an empty manifest but I can mostly guarantee it shouldn't happen.
@freak4pc
Hi, Thank you for your comment.
If Option 2 happens and you release a version, will the signature be included inside?
@freak4pc @danielt1263
The official document clearly states that you are required to add privacy manifest, since you are on the list. And all other SDKs that are not on the list add the manifest only if they have something to add.
If this is not enough for you to make right decision, just show care about all these thousands of developers who use your SDK. Huge amount of apps that use RxSwift faced this challenge of figuring out how to deal with this new Apple requirement. I have 5 apps in the App Store. Each of them uses dozens of SPM dependencies. Each of them receive warnings from Apple about missing API declarations. Instead of looking for a needle in a haystack I would prefer that every SDK developer tell me whether they use these APIs or not.
@freak4pc @danielt1263 The official document clearly states that you are required to add privacy manifest, since you are on the list. And all other SDKs that are not on the list add the manifest only if they have something to add.
If this is not enough for you to make right decision, just show care about all these thousands of developers who use your SDK. Huge amount of apps that use RxSwift faced this challenge of figuring out how to deal with this new Apple requirement. I have 5 apps in the App Store. Each of them uses dozens of SPM dependencies. Each of them receive warnings from Apple about missing API declarations. Instead of looking for a needle in a haystack I would prefer that every SDK developer tell me whether they use these APIs or not.
Wow, you are amazingly rude. We've been maintaining this project for years and putting our heart into it, using ridiculous claims like "showing care for developers" is amazingly detached from reality. I don't know who you are, I've never seen you contribute a single line of code to this project aside for coming here with demands without reading any part of this discussion.
If the decision we took (after consulting the documentation and available online resources) does not suit you, feel free to fork the repo, add an empty manifest and link your apps towards your fork. The project is open and you're free to do so.
For now, the yellow block you screenshotted links to the same section I mentioned earlier that shows this manifest requirement in our case is only required for entirely new apps that add RxSwift or updates of apps that add RxSwift (but didn't have it before).
We've also linked to the DTS answer that mentions there is no need to add an empty manifest if you have nothing to declare.
Beyond that, I really have nothing else to add to this discussion anymore.
We might make a change if Apple answers our DTS but we have not heard back from them so far, we might also make a change at our own discretion (mainly to stop this ridiculous discussion). There is currently no reasoning / guidance of doing what you suggested, the fact you have 5 apps to deal with is not a reason for me to change my answer. I'm maintaining plenty of apps that use RxSwift heavily and am taking the same decision into my projects as well :)
Also, as I've noted, our own app has RxSwift in the App Store with no privacy warnings.
This is how I understand the DTS reply:
if frameworkNeedsPrivacyManifest() {
addPrivacyManifest()
} else {
doNothing()
}
func frameworkNeedsPrivacyManifest() -> Bool {
return frameworkIsOnTheList || frameworkUsesRequiredReasonsAPIs
}
Maybe you're right, maybe I am. But we both see what we want to see.
Wow, you are amazingly rude
This is the way.
You are misinterpreting the text and not referring at all to the huge document with specifications they sent, but I have wasted enough energies on this discussion with you at this point :)
As I mentioned, there is absolutely no problem or difficulty with forking the repo and add or remove whatever portions of code you want to it if you're interpreting the situation any differently. We'll be monitoring what happens to releases in May and if there is any issues / report of an issue. As mentioned numerous times before, if there will be any issue we will immediately remedy with whatever is needed.
Thanks.