What RevenueCat means for your app's privacy disclosures

RevenueCat is subscription and payment infrastructure. What it involves, whether it needs the tracking prompt, what goes on the App Store labels and the Play Data safety form, and the rejection it is usually behind.

Updated 2026-09-18 · Written from the same rules terms.gg uses to generate documents

What RevenueCat actually does

Runs subscriptions across the App Store and Google Play, so entitlement logic lives in one place instead of two.

What its job necessarily involves

These follow from what the thing is for, so they are true whichever version you installed:

• A subscriber identifier, which is either yours or one it generates.
• Purchase and renewal history, since that is the product.
• Receipt data validated against the stores.

What to open and check in RevenueCat

The settings below decide what the honest answer on the forms is, and they are specific to this SDK rather than to its category:

• Whether you pass your own user identifier or let it generate an anonymous one, which decides whether purchase history is linked to an account.
• Whether any attribution integration is connected, because that moves this into advertising.

RevenueCat does not need the tracking prompt

Taking money is not tracking. So RevenueCat does not on its own require App Tracking Transparency. That is a statement about this SDK, not about your app: add one ad network or one attribution tool and the prompt applies to everything.

RevenueCat in Europe: runs on necessity

You cannot deliver the service without it, so RevenueCat generally rests on the contract with your user rather than on consent. Say plainly in the policy that it is a processor, what it does, and where it runs.

RevenueCat in California: probably not a sale

RevenueCat does its job for you rather than for its own commercial purposes, which normally keeps it a service provider rather than a sale. That depends on your contract saying so, and the standard terms usually do.

RevenueCat on the App Store privacy labels

Apple asks what your app collects, and your app collects whatever its SDKs collect. RevenueCat is generally declared under App Functionality, alongside whatever the rest of your app does for its own reasons.

RevenueCat on the Google Play Data safety form

The form asks two things the labels do not: whether data is shared with anyone else, and whether it is encrypted in transit. For this SDK the honest answer is usually collected but not shared, because it processes on your behalf.

Check RevenueCat's own privacy manifest for RevenueCat

Since 2024 Apple has required third-party SDKs on its list to ship a signed privacy manifest declaring what they collect and which sensitive APIs they use, and your app's combined manifest is built from them. That file is the authoritative answer for RevenueCat, it comes from RevenueCat, and it changes when they ship.

The rejection RevenueCat is usually behind

Purchase history is declared as not collected because the developer thought only Apple held it.

What to put in the privacy policy about RevenueCat

• RevenueCat named as a processor or a recipient, not hidden behind "our partners".
• What it is for, in a sentence someone would understand without knowing what an SDK is.
• Where it runs, and what makes a transfer outside your region lawful.
• How long the data is kept, which is a question the vendor documents and most policies skip.
• That it processes on your instructions rather than for its own purposes.

Keeping it true after launch

A legal page stops being true the moment the product moves past it, usually by adding a payment provider, an analytics SDK or a sign-in. No store re-checks your pages against your build, so the drift is yours to notice.

• Re-read it whenever you add a dependency that sees user data.
• Re-check what loads on the page after any change: the cookie notice and the policy have to agree.
• Keep the URL stable. Changing where a policy lives breaks every listing that points at it.