Guideline 5.1.2 - Legal - Privacy - Data Use and Sharing: Missing Data Collection Precautions and User Consent

This rejection is part of Apple's standard 5.1.2 template that appears whenever a reviewer sees an app requesting access to personal data (most commonly Contacts, but also Photos, Location, or Calendar) without being able to verify — through the UI alone — that the user was told the data would be uploaded to a server and given a chance to consent or opt out.

The specific line inviting you to 'confirm if the app does not actually upload Contacts' is a strong signal this is semi-automated: Apple's static analysis detected a data-access API or entitlement (e.g., Contacts framework) and the reviewer could not confirm server-side handling during a manual pass, so they defaulted to the boilerplate privacy-consent rejection.

There are two distinct root causes, and the fix depends entirely on which one applies to your app:

1. The app never sends this data off-device — in which case this is a false positive from the reviewer's perspective, and the fastest path is a factual clarification, not a code change

2. The app does upload data (contacts, location, etc.) to a server for features like 'find friends,' backup, or sync — in which case Apple's requirement for an explicit consent step and an opt-out mechanism is genuinely applicable and unambiguous

The fastest compliant path that preserves your business model is to first determine which scenario applies. If no upload occurs, reply directly in Resolution Center and update App Review Information — this typically resolves in hours with no code change. If upload does occur, add a clear pre-upload consent screen and a settings-level opt-out; this is a contained, well-defined engineering task that does not require altering your underlying data or monetization model.