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

**Guideline:** 5.1.2 · **Store:** Apple App Store · **Severity:** medium · **Fix difficulty:** medium · **Typical turnaround:** 1-3 days

Canonical URL: https://appstorereject.com/rejections/apple/5/guideline-512-legal-privacy-data-use-and-sharing-missing-data-collection-precautions-and-user-consen

## Description

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.

## Common variations

- The app accesses user data from the device but does not have the required precautions in place (generic, data type unspecified).
- Your app requests access to the user's Contacts/Photos/Location, but does not clearly disclose that this data will be uploaded to a server before upload occurs.
- We were unable to locate a consent mechanism prior to data collection. Please add an explicit consent step and confirm whether data is transmitted off-device.
- The app does not provide users the ability to opt out of having their personal data stored on your servers.
- If your app does not upload [Contacts/Location/Photos] data to a server, reply to confirm this and update your App Review Information accordingly.

## Example rejection email

```
Guideline 5.1.2 - Legal - Privacy - Data Use and Sharing

Issue Description
The app accesses user data from the device but does not have the required precautions in place.

Next Steps
To collect personal data with the app:
- The app must make it clear to the user that their personal data will be uploaded to a server and the user must provide consent before the data is uploaded.

If the app does not actually upload the user's Contacts to a server, reply to this rejection to confirm and add this information to the App Review Information section of App Store Connect.

- Users must also have the option to opt-out from having their data stored on your server.
```

## Resolution steps

## Quick Assessment
- **Risk level:** Medium
- **Resolution path:** Clarify Without Change (if no upload occurs) OR Fix & Resubmit (if upload occurs)
- **Typical turnaround:** 1-3 days

## The Fix

01. **Determine actual data flow**
   Audit the exact API calls (e.g., CNContactStore, PHPhotoLibrary, CLLocationManager) that triggered the flag. Confirm definitively whether that data is ever transmitted to a server, third-party SDK, or analytics endpoint.

02. **If no server upload occurs — clarify, don't code**
   Reply in Resolution Center confirming the data stays on-device (e.g., "Contacts data is used only locally for [feature] and is never transmitted to any server"). Add the same statement to the App Review Information notes field in App Store Connect, and resubmit without a build change if possible.

03. **If server upload does occur — add explicit pre-upload consent**
   Before any personal data leaves the device, present a clear, dedicated screen (not just the system permission prompt) explaining what data is collected, why, and that it will be stored on your server. Require an affirmative user action (e.g., "Allow & Continue") before the OS permission prompt or upload call fires.

04. **Add an opt-out control**
   Provide a persistent, discoverable setting (e.g., Settings > Privacy > "Stop syncing my Contacts" / "Delete my data from server") that lets users disable future uploads and, ideally, request deletion of already-stored data.

05. **Update your Privacy Policy and Nutrition Label**
   Ensure the privacy policy explicitly names the data type, purpose, and third parties (if any), and that your App Store privacy "nutrition label" answers match actual behavior.

06. **Document the flow for the reviewer**
   In App Review Information, add step-by-step navigation instructions (e.g., "Tap Sync Contacts on the Friends tab to see the consent screen") so the reviewer can locate the consent/opt-out UI without guessing.

## Prevention
- Always place a custom consent screen before any OS permission prompt that leads to server upload — never rely on the system dialog alone as your "consent."
- Build the opt-out into settings from day one for any feature that syncs personal data.
- Keep App Review Information notes updated with a plain-language description of what data is collected, where it goes, and how to test the consent flow.

## Appeal guidance

The guideline text itself (5.1.2 ii-vii) governs repurposing, profiling, and specific API categories — it does not explicitly mandate a dedicated in-app opt-out toggle for every data type; that requirement comes from Apple's applied 'Next Steps' template. If your app does not upload the flagged data at all, this is not a violation but a verification gap, and a factual clarification is the correct and fast response. If your app already presents clear consent language (even via a well-labeled permission prompt with contextual text) and reasonable data controls, there is room to argue the reviewer's interpretation added a stricter requirement than the guideline text specifies. Appeal is viable in both scenarios; only skip appeal and go straight to a build fix if you confirm data is uploaded with no consent or opt-out mechanism anywhere in the app.

## Before / after examples

**Before:** App requests Contacts access via the system permission prompt only, then silently uploads contacts to the server for a 'find friends' feature.
**After:** App shows a custom pre-permission screen explaining that contacts will be uploaded to find friends, requires explicit user confirmation, and offers a Settings toggle to stop syncing and delete stored contacts.
**Why it works:** Explicit pre-upload consent and a discoverable opt-out satisfy Apple's stated Next Steps requirements.

**Before:** Reviewer flags Contacts access; in reality the app only reads contacts locally to autofill a form field and never sends the data anywhere.
**After:** Developer replies in Resolution Center confirming no server transmission occurs and adds the same statement to App Review Information notes.
**Why it works:** When no data leaves the device, the guideline does not apply, and clarification resolves the flag without any code change.

## Common questions

**Can you appeal a 5.1.2 rejection?**

The guideline text itself (5.1.2 ii-vii) governs repurposing, profiling, and specific API categories — it does not explicitly mandate a dedicated in-app opt-out toggle for every data type; that requirement comes from Apple's applied 'Next Steps' template. If your app does not upload the flagged data at all, this is not a violation but a verification gap, and a factual clarification is the correct and fast response. If your app already presents clear consent language (even via a well-labeled permission prompt with contextual text) and reasonable data controls, there is room to argue the reviewer's interpretation added a stricter requirement than the guideline text specifies. Appeal is viable in both scenarios; only skip appeal and go straight to a build fix if you confirm data is uploaded with no consent or opt-out mechanism anywhere in the app.

**How long does this typically take to fix?**

Typical turnaround is 1-3 days (difficulty: medium). After resubmission, most re-reviews complete within 24-48 hours.

---
*Machine-readable source: https://api.appstorereject.com/api/rejections/detail?slug=guideline-512-legal-privacy-data-use-and-sharing-missing-data-collection-precautions-and-user-consen*