RevenueCat and Apple App Privacy labels: what to select in App Store Connect

What RevenueCat actually sees

RevenueCat sits between your app and the App Store's payment system. It does not process card details — Apple does that — but it does receive and store purchase and entitlement data so it can tell your app which subscriptions or products a user has active. That purchase history is the one fact almost every RevenueCat integration produces, which is why the Service Profile marks it as likely rather than merely possible.

What RevenueCat does not automatically receive is personal information beyond that. Email addresses, names, or other customer attributes only reach RevenueCat if your code sends them, typically through its customer attributes API. Installing the SDK for subscription management is not evidence that you are doing this.

The app user ID question

RevenueCat identifies each customer with an app user ID. By default this can be an anonymous identifier RevenueCat generates itself, or you can set your own — often the same ID your backend or auth provider already uses for that person. This distinction matters for your App Privacy answer, because a RevenueCat-generated anonymous ID and a developer-set ID tied to a signed-in account are different facts about linkage.

If you map your own account ID onto RevenueCat's app user ID, that identifier is linked to the user's identity elsewhere in your system, and your Identifiers answer should reflect that. If you never set one and let RevenueCat manage anonymous IDs, the linkage story is weaker, but purchase history collection still applies.

Purchases is not optional once subscriptions exist

Apple's App Privacy form has a dedicated Purchases category covering purchase history. Because RevenueCat's core function is tracking what a customer bought or is entitled to, this category applies to essentially every app that uses it for its intended purpose. Declaring "Data Not Collected" for Purchases while shipping paid subscriptions through RevenueCat is a direct contradiction a reviewer running your app can observe by reaching your paywall.

This is separate from whether the purchase itself is processed by Apple. Apple's own collection of payment details for the transaction is not what your App Privacy label is describing here — the label describes what your app and the SDKs inside it collect, and RevenueCat's entitlement records fall inside that scope.

Email and customer attributes are configuration-dependent

RevenueCat supports attaching customer attributes — email, display name, or custom fields you define — to a subscriber record, commonly used for CRM sync or targeted messaging about a specific plan. None of this is automatic. If your app sends a user's email to RevenueCat as a customer attribute, that is collection you declare under Contact Info. If you never call that part of the SDK, it is not.

The mistake to avoid here runs in both directions: assuming RevenueCat never touches email because it is "just a billing SDK," and assuming it always does because email attributes exist as a feature. Check your own integration code for calls that set customer attributes before answering.

Common mistake

The most common mistake is treating RevenueCat as invisible because Apple processes the actual card transaction. Apple's App Privacy form is about what data your app and its third-party SDKs collect, not only what your own servers receive directly, and RevenueCat's purchase and entitlement records are collected in that sense regardless of who charges the card.

A second common mistake is copying an app user ID answer from a different app. Whether your app's RevenueCat identifier is linked to the user depends entirely on whether you set it to match your own account system — a decision unique to your codebase, not something the SDK's documentation can answer for you.

Why apps get rejected

Rejections tied to subscription infrastructure tend to cluster around Guideline 5.1.1 and mismatches between the label and observable app behavior:

• App Privacy answers that omit Purchases while the app clearly sells auto-renewable subscriptions.
• A privacy policy that never mentions subscription or purchase data while the app processes payments through RevenueCat.
• Customer attribute collection (email, name) implemented in code but absent from the declared data types.

Because a paywall and a completed purchase flow are two of the most visible things in a review session, an inaccurate Purchases declaration is one of the easier inconsistencies for a reviewer to catch.

Where Declora fits

Declora's RevenueCat Service Profile suggests App Facts for purchase history, app user ID, and subscription status with a confidence level and a reason attached to each, then asks the two questions that cannot be inferred from the SDK alone: whether you set your own app user ID, and whether you send email or other attributes. Once you confirm those, Passport Readiness generates your Apple and Google Play answers from the same confirmed App Facts, so a change you make later regenerates every output instead of leaving one platform's label out of date. Declora does not scan your code and does not guarantee approval by Apple, Google, or any regulatory authority — it is a way to keep your own confirmed answers consistent everywhere they appear.

FAQ

Does using RevenueCat mean I have to declare Purchases even though Apple processes the payment?

Yes, in almost every real integration. RevenueCat's function is to receive and store purchase and entitlement records so your app can check subscription status, and that record-keeping is collection your App Privacy label needs to reflect, independent of who processes the card transaction itself.

Is the RevenueCat app user ID always linked to the user's identity?

Not automatically. If it is an anonymous identifier RevenueCat generates, linkage is weaker. If you set it to your own account ID, it is tied to the user's identity through your own system, and your Identifiers answer should say so.

Do I need to declare email collection just because RevenueCat supports customer attributes?

No. Customer attributes like email are only collected if your integration code sends them. Check your own calls to the customer attributes API before answering — the feature existing in the SDK is not evidence it is used in your app.

Does RevenueCat process my users' card details?

No. Apple and Google process the actual store transaction. RevenueCat receives purchase and entitlement metadata after the fact so your app can determine what a customer is entitled to.

Can Declora tell me for certain which answers to select?

No. The Service Profile suggests App Facts with a confidence level and asks the configuration-dependent questions your own integration determines. You confirm the answers; Declora then keeps your Apple and Google Play declarations and Public Pages consistent with what you confirmed. It does not provide legal advice and cannot guarantee approval.