Update privacy info

[catarinapeixoto]

This PR fixes PrivacyInfo.xcprivacy file.

[ashleymills]

CA92.1 is defined as:

"Declare this reason to access user defaults to read and write information that is only accessible to the app itself."

which doesn't seem right as the code doesn't access UserDefaults. Is there a more appropriate value to use, or can the array be empty if none apply?

[albinjohnson01]

According to apple documentaion we can't keep empty array for below key's , If we are not using in our framework better remove instead of keeping as empty.

NSPrivacyTrackingDomains
NSPrivacyCollectedDataTypes
NSPrivacyAccessedAPITypes

[catarinapeixoto]

@adzerjitchii @fxwx23 @SethBaldwin @closure11 @tommyming @lpbas @mmackowiak @marcuseckert

[catarinapeixoto]

@ashleymills

[ashleymills]

@adzerjitchii @fxwx23 @SethBaldwin @closure11 @tommyming @lpbas @mmackowiak @marcuseckert

As previous contributors to this topic, do you have any thoughts/opinions on this PR?

[mmackowiak]

As previous contributors to this topic, do you have any thoughts/opinions on this PR?

Given what's stated in documentation:

For each category of required reason API that your app or third-party SDK >>>uses<<<, add a dictionary to the NSPrivacyAccessedAPITypes array in your app or third-party SDK’s privacy manifest file that reports the reasons your app uses the API category

and the fact Reachability.swift doesn't use NSUserDefaults, I personally believe it should just stay as it is (is == proposed in PR with fix).

[catarinapeixoto]

As previous contributors to this topic, do you have any thoughts/opinions on this PR?

Given what's stated in documentation:

For each category of required reason API that your app or third-party SDK >>>uses<<<, add a dictionary to the NSPrivacyAccessedAPITypes array in your app or third-party SDK’s privacy manifest file that reports the reasons your app uses the API category

and the fact Reachability.swift doesn't use NSUserDefaults, I personally believe it should just stay as it is (is == proposed in PR with fix).

If it stays as it is we receive a warning when uploading the app into the store, saying that file is not valid

[mmackowiak]

If it stays as it is we receive a warning when uploading the app into the store, saying that file is not valid

I think I introduced a confusion, to rephrase - current state, therefore what's in version 5.2.3, seems to be a correct way, that so far did not yield warning for me (last upload to App Store - 6th of September). That's possible something has changed since then, but I agree with @ashleymills that providing some reason shouldn't be necessary, as this library doesn't use NSUserDefaults.

[tommyming]

@adzerjitchii @fxwx23 @SethBaldwin @closure11 @tommyming @lpbas @mmackowiak @marcuseckert

As previous contributors to this topic, do you have any thoughts/opinions on this PR?

Thanks for the tag @ashleymills!
As I have checked from 5.2.0 to 5.2.3, there isn't anything new introduced to the privacy manifest.
The fix should not work this way, because if we haven't used any of NSUserDefaults, we shouldn't declare the usage.

One possible cause I could think of is the path of the privacy manifest in Package.swift.
As I saw from other repositories, some of them are declared as
Resources/PrivacyInfo.xcprivacy instead of PrivacyInfo.xcprivacy
This could be the reason why App Store Connect cannot find the privacy manifest.

Just ping me if there are any problem related to this.

[NikiforosDesquared]

Greetings, do we have any update on this? What should we do to avoid having this warning from apple?

[belousovgm]

Hello folks, any updates here?

[ashleymills]

I merged in #420 which removes unused keys. Please try the latest release 5.2.4, if that doesn't work we'll try something else