Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid reason on xcprivacy report file: Privacy Accessed API Types USERDEFAULT #3758

Open
6 of 12 tasks
jesus-mg-ios opened this issue Mar 11, 2024 · 3 comments
Open
6 of 12 tasks
Labels

Comments

@jesus-mg-ios
Copy link

Describe the bug
The reason exposed is

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.

Instead of:

1C8F.1
Declare this reason to access user defaults to read and write information that is only accessible to the apps, app extensions, and App Clips that are members of the same App Group as the app itself.
This reason does not permit reading information that was written by apps, app extensions, or App Clips outside the same App Group or by the system. This reason also does not permit writing information that can be accessed by apps, app extensions, or App Clips outside the same App Group.

Revenuecat uses user default app group to communicate extensions and apps.
https://www.revenuecat.com/docs/getting-started/configuring-sdk/ios-app-extensions

  1. Environment
    1. Platform:
    2. SDK version:
    3. StoreKit version:
      • StoreKit 1
      • StoreKit 2 (enabled with usesStoreKit2IfAvailable(true))
    4. OS version:
    5. Xcode version:
    6. Device and/or simulator:
      • Device
      • Simulator
    7. Environment:
      • Sandbox
      • TestFight
      • Production
    8. How widespread is the issue. Percentage of devices affected.
  2. Debug logs that reproduce the issue. Complete logs with Purchases.logLevel = .verbose will help us debug this issue.
Logs here
  1. Steps to reproduce, with a description of expected vs. actual behavior

Please fill in

  1. Other information (e.g. stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, etc.)

  2. Additional context
    Add any other context about the problem here.

@RCGitBot
Copy link
Contributor

👀 We've just linked this issue to our internal tracker and notified the team. Thank you for reporting, we're checking this out!

@jesus-mg-ios
Copy link
Author

Also it's rare that the purchase history is not linked to the user. Is it right?

@aboedo
Copy link
Member

aboedo commented Mar 11, 2024

@jesus-mg-ios the currenty privacy report is based on default usage of the SDK, so your mileage may vary depending on how you use the SDK.

Sadly there isn't a way for us to know beforehand how exactly your app will use our SDK, so the privacy report assumes a minimal implementation.

For example, if you rely solely on RevenueCat's Anonymous IDs, those are not tied to a user in any traceable way, which is why the purchase data isn't linked to a user. If you use logIn, logOut, or pass in an appUserID when configuring, however, then you would need to check "purchase history linked to the user".

Similarly, for App Groups, a default implementation would use UserDefaults without App Groups, so the relevant reason would be CA92.1 unless you actually configure using UserDefaults for App Groups.

You can find out more here:
https://www.revenuecat.com/docs/platform-resources/apple-platform-resources/apple-app-privacy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants