← Field notes

Privacy

The App Privacy label trap

Over-declaring is as wrong as under-declaring. The label has to match what your app actually does.

The App Privacy “nutrition label” is where a lot of first apps trip — and the mistake is usually over-declaring, not hiding something. Checking boxes to look thorough is a rejection risk (Guideline 5.1.1), same as leaving true ones unchecked. It has to match reality. And it has to be Published, not just saved.

The fork nobody spells out — it depends on how you sell:

StoreKit direct (no third-party SDK, no analytics)

You collect nothing. Apple runs the transaction; you receive nothing and store nothing off the device. Your answer is Data Not Collected. Publish it and move on. This is the honest label for a truly on-device app.

RevenueCat (or any purchases/analytics SDK)

Now something is collecting purchase data, even though your users’ own data stays on their phone. Declare Purchases — and only Purchases, if you use anonymous IDs (the default). Not User ID, not Device ID, not Location. Mark it App Functionality and Analytics, Not Linked, Not Tracking.

The trap is assuming “I have in-app purchases, so I must collect Purchases.” Not if Apple’s the one processing it and you run no SDK. The question isn’t “is money changing hands” — it’s “does your code, or a library you shipped, collect the data.” Answer that honestly and the label writes itself.

---

The full playbook — every screen, in order — is in the guides.