Guideline 5.1.1: Data Collection and Privacy
Your app was rejected for collecting too much data, not being transparent about it, or handling it improperly. Here's what Apple expects and exactly how to fix it.
📋 TL;DR - Privacy Requirements
- • Only collect data you actually need
- • Explain clearly WHY you need each piece of data
- • Fill out App Privacy details accurately in App Store Connect
- • Purpose strings must be specific, not generic
- • Third-party SDKs count—know what they collect
What is Guideline 5.1.1?
Guideline 5.1.1 covers data collection, storage, and use. Apple summarizes it as:
"Apps must respect user privacy by being transparent about data collection. Apps that collect user or device data must secure user consent, and make a privacy policy available that clearly describes your use of data."
This sounds simple, but 5.1.1 is one of the broadest guidelines and covers many specific requirements:
5.1.1(i) - Data Collection
Only collect data that's directly relevant to your app's core functionality. No hoarding "just in case."
5.1.1(ii) - Data Use
Data must be used only for what you disclosed. No secret monetization or sharing with third parties.
5.1.1(iii) - Permissions
Request permissions only when needed, with clear purpose strings explaining why.
5.1.1(v) - ATT
If you track users across apps/websites, you must use App Tracking Transparency.
Common 5.1.1 Violations
These are the issues I see developers get rejected for repeatedly:
1 Requesting Permissions You Don't Need
Your calculator app asks for camera access. Your note-taking app wants location. Apple's question: "Why?"
Fix: Only request permissions that are essential for core features. If it's for an optional feature, request it at the moment the user tries to use that feature—not at launch.
2 Vague or Generic Purpose Strings
"We need camera access to enhance your experience." What experience? This tells the user nothing.
Fix: Be specific. "Camera access is needed to scan QR codes for quick login." Now the user understands.
3 Privacy Label Mismatch
Your App Privacy label says "No data collected" but your app uses Firebase Analytics, Facebook SDK, or other data-collecting SDKs.
Fix: Audit every SDK in your app. Update your privacy label to accurately reflect what's collected—even by third parties.
4 Collecting Data Before Consent
Analytics fire on launch before the user even sees your privacy policy or agrees to anything.
Fix: For EU users (GDPR), you need explicit consent before tracking. Consider delaying analytics initialization until after consent is given.
5 No Privacy Policy or Inaccessible URL
Your privacy policy link returns a 404, or you don't have one at all.
Fix: Every app that collects any data needs a privacy policy. Host it on a stable URL and verify it loads before submitting.
Privacy Nutrition Labels
Since December 2020, every app on the App Store must have privacy "nutrition labels" that tell users what data you collect. These appear on your App Store listing before users download.
How to Fill Them Out
Go to App Store Connect → App Privacy
Under your app, click "App Privacy" in the left sidebar.
For Each Data Type, Answer Honestly
Apple lists categories (Contact Info, Location, Identifiers, etc.). For each, specify if you collect it, and if so, how it's used and whether it's linked to the user.
Include Third-Party SDK Data
Firebase collects device IDs. Facebook SDK collects usage data. You're responsible for disclosing everything your app collects, directly or through SDKs.
Apple Verifies This
Apple's reviewers do check. They analyze your binary for known SDKs and compare against your declarations. If there's a mismatch, you'll get a 5.1.1 rejection asking you to update your privacy labels.
Data Categories You Might Forget
| SDK/Feature | Data Collected |
|---|---|
| Firebase Analytics | Device ID, Usage Data, Diagnostics |
| Firebase Crashlytics | Crash Logs, Device ID, Diagnostics |
| Facebook SDK | Device ID, Advertising Data, Usage Data |
| AdMob / Google Ads | Device ID, Location (if allowed), Advertising Data |
| Mixpanel / Amplitude | Usage Data, Device ID |
| Push Notifications | Device Token (counts as Identifiers) |
Writing Good Purpose Strings
Purpose strings appear when iOS asks for permission (camera, location, etc.). Apple reviews these carefully. Generic strings get rejected.
Bad Purpose Strings
- ❌ "Camera access is required"
- ❌ "We need your location"
- ❌ "This app needs photos access"
- ❌ "Allow access for a better experience"
- ❌ "Please allow all permissions"
Good Purpose Strings
- ✓ "Camera is used to scan product barcodes for price comparison"
- ✓ "Your location helps find nearby restaurants"
- ✓ "Photo library access allows you to attach images to your journal entries"
- ✓ "Microphone is needed to record voice memos for your notes"
All Required Purpose String Keys
<!-- Info.plist keys you might need -->
<key>NSCameraUsageDescription</key>
<string>Take photos for your profile and posts</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>Select photos from your library to share</string>
<key>NSLocationWhenInUseUsageDescription</key>
<string>Find stores and events near you</string>
<key>NSMicrophoneUsageDescription</key>
<string>Record audio messages to send to friends</string>
<key>NSContactsUsageDescription</key>
<string>Find friends who are also using this app</string>
<key>NSCalendarsUsageDescription</key>
<string>Add events to your calendar from the app</string>
<key>NSUserTrackingUsageDescription</key>
<string>Allow tracking to receive personalized ads</string>
Data Minimization
Apple's philosophy is simple: collect only what you need. If a feature can work without certain data, don't collect it "just in case."
Ask: Do You Really Need This?
Before adding any data collection, ask if the feature works without it. Can you use on-device processing instead of cloud? Can you anonymize the data?
Request at the Right Time
Don't request all permissions at launch. Request them when the user tries to use the feature that needs them. This is also better UX—users understand why you're asking.
Delete When No Longer Needed
Don't hoard data forever. If a user deletes their account, actually delete their data. Apple (and GDPR) expects this.
Third-Party SDKs
This is where most developers get caught. You add Firebase for analytics, not realizing it collects device IDs. You include an ad SDK that tracks users. Apple holds YOU responsible for what these SDKs do.
How to Audit Your SDKs
- List every SDK in your project (check Podfile, Package.swift, build phases)
- Check each SDK's privacy documentation—most major SDKs now publish what they collect
- Update your privacy labels to include everything your SDKs collect
- Consider alternatives if an SDK collects more than you're comfortable disclosing
Privacy Manifests (iOS 17+)
As of iOS 17, SDKs must include privacy manifests declaring what data they access. Xcode can generate a privacy report showing all APIs your app uses. Run Product → Analyze → Generate Privacy Report to see what needs to be declared.
Frequently Asked Questions
Does "Data Not Collected" mean I can't use any analytics?
No. You can use analytics, but you must disclose it. "Data Not Collected" means you genuinely collect nothing—no analytics, no crash reports, no identifiers at all. If you use any SDK that phones home, you're collecting data.
What if an SDK collects data I can't control?
You still have to disclose it. That's the deal with using third-party code. If you're not comfortable with what an SDK collects, find an alternative or build the functionality yourself.
My app works fine without location, but users might want it. Should I still request it?
Only if you have a feature that uses it. Don't request location "in case" the user wants it someday. Implement the feature first, then request permission when they try to use it.
Can I change my privacy labels after the app is live?
Yes. Privacy labels aren't locked to a specific version. You can update them anytime in App Store Connect. Just be aware that changes are visible to users.
What's the difference between "Data Used to Track You" and "Data Linked to You"?
"Track" means the data is used to follow users across apps or websites for advertising. "Linked" means the data is connected to the user's identity but stays within your app. Both must be disclosed, but they appear differently on the App Store.
Audit Your Privacy Compliance
Our AI Review Toolkit includes prompts to analyze your app's data collection practices and privacy declarations. Catch 5.1.1 issues before Apple does.
Get the AI Toolkit