RevenueCat sends user data to RevenueCat, Inc. Every purchase and restore in your app transfers a receipt, an app user identifier, and device metadata to a third party, so you have to disclose it. Generate a full privacy policy with this clause built in →
Does RevenueCat need a privacy policy disclosure?
RevenueCat is a subscription and in-app purchase management layer that sits between your app and the Apple App Store and Google Play billing systems. When a user buys or restores a subscription, the SDK sends the store receipt or purchase token, an app user ID (a random anonymous ID unless you provide your own), and device and platform data to RevenueCat's servers. RevenueCat validates the purchase, decides which entitlements the user has, watches for receipt fraud, and builds the charts you see in its dashboard.
That is a transfer of personal data to a third-party processor, so it belongs in your privacy policy. RevenueCat's iOS SDK ships a PrivacyInfo.xcprivacy manifest with NSPrivacyTracking set to false, so RevenueCat by itself is not "tracking" under Apple's App Tracking Transparency rules or Guideline 5.1.2 — unless you connect a cross-app advertising or attribution integration (AppsFlyer, Adjust, Branch, Facebook, Apple Search Ads), which can change that answer.
What data does RevenueCat collect?
| Data type | Purpose | Linked to the user? | Used for tracking? |
|---|---|---|---|
App user ID (anonymous $RCAnonymousID or developer-provided) | Identify the customer, sync entitlements across devices | Only if you set an ID tied to identity; anonymous IDs: no | No |
| Purchase history, store receipt and transaction identifiers | Receipt validation, fraud prevention, entitlements, dashboard analytics | Yes (to the app user ID) | No |
| Device and platform data (OS version, RevenueCat SDK version, country, locale, currency) | App functionality, charts | Linked to app user ID | No |
| Attribution data forwarded from AppsFlyer / Adjust / Branch / Apple Search Ads (only if you enable an integration) | Marketing attribution, campaign reporting | Yes | Potentially yes — ad-network attribution can count as tracking |
| IDFA / advertising ID (only if you pass it through the Attribution API) | Ad attribution | Yes | Yes |
The exact list depends on your configuration: whether users are anonymous or identified, whether you call logIn() with a real user ID, and which integrations and attribution SDKs you enable. Confirm your own setup before you fill out any store form.
Copy-paste privacy policy clause for RevenueCat
Subscription and in-app purchase management (RevenueCat)
This app uses RevenueCat, a subscription management service provided by
RevenueCat, Inc. RevenueCat sits between the app and the Apple App Store
and Google Play billing systems. When you make or restore a purchase, we
send RevenueCat your purchase receipt and transaction identifiers, an app
user identifier (anonymous unless you sign in), your device platform and
operating system version, and your country, locale, and currency.
RevenueCat uses this data on our behalf to validate purchases, prevent
payment fraud, determine which features you are entitled to, and provide
us with subscription analytics. If we have enabled an attribution
integration, RevenueCat may also receive marketing attribution data
(including, where applicable, advertising identifiers) linked to your app
user ID. RevenueCat acts as our data processor. See RevenueCat's privacy
policy at https://www.revenuecat.com/privacy/.Adapt this: delete the attribution sentence if you do not use any attribution integration; if you call Purchases.configure with an ID that identifies a person (their email or your database ID), say so and treat purchase data as linked to identity.
App Store "App Privacy" label answers
In App Store Connect, declare at least the following for RevenueCat:
- Purchases > Purchase History — purposes: "App Functionality" (receipt validation, entitlements) and "Analytics" (dashboard charts and experiments). Linked to the user: Yes, unless you keep users strictly anonymous. Used to track you: No, by default.
- Identifiers > User ID — only if you set an app user ID tied to a real identity. Purpose: "App Functionality". Linked: Yes. Used to track you: No.
- Identifiers > Device ID — only if you forward the IDFA or an advertising ID through the Attribution API. Purpose: "Third-Party Advertising". Linked: Yes. Used to track you: Yes — and you must show the ATT prompt first.
RevenueCat's SDK privacy manifest also declares a "reason" for accessing UserDefaults; you do not add that to your label, but keep the bundled manifest in your build.
Google Play Data Safety answers
For the Play Console Data safety form:
- Financial info > Purchase history — Collected: Yes. Shared: No for RevenueCat itself (it is a service provider processing on your behalf); Yes if you enable an ad-network attribution integration that forwards data onward. Purposes: App functionality, Analytics.
- App activity > App interactions — subscription and purchase events. Collected: Yes. Shared: No. Purpose: Analytics.
- Device or other IDs — Collected: Yes only if you pass an advertising ID or enable device-identifier collection. Shared: Yes in that case. Purpose: Advertising, Analytics.
- Data is not processed ephemerally — RevenueCat stores customer records. Users can request deletion; you can delete a customer from the RevenueCat dashboard or via its API.
RevenueCat-specific gotchas
- Anonymous by default. If you never pass an
appUserID, RevenueCat generates a random$RCAnonymousID. You still declare "Purchases", but you can answer "not linked to the user". - logIn() changes your label. Configuring RevenueCat with an email or your own user ID makes purchase data linked to identity — update the App Privacy label and Data Safety form.
- Attribution turns it into tracking. Passing IDFA, IDFV, or push tokens, or enabling Adjust / AppsFlyer / Branch / Facebook integrations, can make RevenueCat usage "tracking" and requires the ATT prompt plus the "Used to track you" label.
- Receipts are purchase data, not "financial info". The full App Store receipt RevenueCat receives is transaction data; do not mislabel it as payment or bank details.
- The bundled manifest is a floor, not a ceiling. RevenueCat's default privacy manifest reflects only out-of-the-box behavior; if you enable device-identifier collection you must update your own app's manifest and labels.
- You, not RevenueCat, are responsible for the accuracy of these disclosures and for signing RevenueCat's DPA if your regulator requires one. This clause is a starting template, not legal advice.
Related
See the sibling clauses for Superwall, Stripe, Supabase, and Google Sign-In. To assemble the whole document, use the privacy policy page generator, and see the Firebase privacy policy guide if your app also uses Firebase.