If you are an iOS developer, there is one step in the submission process that likely spikes your heart rate more than the actual App Review: The "App Privacy" section in App Store Connect.
Back when Apple introduced Privacy Nutrition Labels, it was just a "good to have." Now, in 2026, with the strict enforcement of Privacy Manifests and the tracking of APIs, getting this wrong isn't just about bad opticsβit can get your binary rejected or your account flagged.
If you are staring at the "Data Types" screen wondering if you need to declare "Device ID" or "Product Interaction" for your analytics tool, this guide is for you. We will break down exactly how to fill this out, compare the heavy requirements of tools like Firebase vs. privacy-first alternatives, and show you how to legitimately keep your label clean.
β‘ Why This Matters (Beyond Compliance)
Your Privacy Label appears right on your App Store product page. Users are increasingly privacy-savvy; a label that scrolls for three pages listing "Location," "Contact Info," and "Identifiers" is a conversion killer.
Furthermore, Apple's Privacy Manifest system (introduced in iOS 17) now technically enforces what you declare. If your code (or your analytics SDK) accesses certain APIs without declaring valid reasons, your build can fail validation before it even reaches a reviewer.
π Step-by-Step: Filling Out The Label
Navigate to App Store Connect β Your App β App Privacy. Here is the 3-step workflow:
1. Data Collection: The "Yes/No" Gate
The first question is simple but dangerous: "Do you or your third-party partners collect data from this app?"
If you use Firebase, Mixpanel, Amplitude, or Facebook SDK, the answer is YES.
2. Data Types
If you answered "Yes," you must check every category that applies. For most apps using standard analytics, these are the usual suspects:
- β’ Identifiers: Device ID (IDFA, IDFV) or User ID
- β’ Usage Data: Product Interaction (taps, screen views)
- β’ Diagnostics: Crash Data, Performance Data
- β’ Location: Coarse Location (often derived from IP addresses)
3. Data Linked to the User
This is the most critical distinction:
- β Linked to User: The data is tied to their identity (email, user ID, or a persistent device ID that creates a profile).
- β Not Linked to User: The data is collected, but cannot be used to identify the specific person (e.g., aggregate data or ephemeral session tokens).
According to Apple, for data to be "not linked," you must strip direct identifiers before collection and never attempt to re-link the data to a user's identity.
βοΈ The Comparison: Firebase vs. Respectlytics
This is where your choice of analytics tool determines whether your privacy label looks like a "Warning" sign or a "Minimal" disclosure.
Option A: Firebase Analytics (The "Heavy" Label)
Because Firebase relies on IDFV (Identifier for Vendor) and can link behavior to persistent IDs for retention tracking, you generally must declare:
| Data Type | Linked to User? |
|---|---|
| Identifiers (Device ID) | Often YES |
| Location (Coarse) | Depends on config |
| Usage Data (Product Interaction) | YES |
| Diagnostics (Crash Data) | YES |
The Result: Your App Store page may show "Data Used to Track You" or "Data Linked to You," which can deter privacy-conscious users.
Option B: Respectlytics (The "Minimal" Label)
Respectlytics is designed around data minimization. Here's what we actually store:
| Data Type | What Respectlytics Stores | Linked? |
|---|---|---|
| Identifiers | None. No Device IDs, IDFA, or persistent user IDs. | NO |
| Location | Country code only (derived from IP, then IP discarded) | NO |
| Usage Data | Product Interaction (event names only) | NO |
| Diagnostics | None. We don't collect crash data. | N/A |
The Result: You declare "Location: Coarse Location" and "Usage Data: Product Interaction" under "Data Not Linked to You."
Why "Not Linked to User"?
Our session IDs exist only in device RAM (never written to disk), rotate every 2 hours or when the app restarts, and are hashed server-side with a daily-rotating salt before storage. This means even we cannot reconstruct a user's activity across sessions or days.
β¨ How to Minimize Your Privacy Label (Legitimately)
You cannot lie on this formβApple's tooling can detect SDK signatures and API usage. However, you can choose tools that require less data.
1. Stop Collecting "Identifiers"
The "Identifiers" category is the scariest one for users. It implies you are building a profile on them.
The Fix: Switch to an analytics provider that uses session-based tracking rather than user-based tracking. If the ID is ephemeral, stored only in RAM, and rotates frequently, it is not a persistent identifier.
2. Handle "Coarse Location" Correctly
If your analytics tool derives country from IP addresses (which Respectlytics does), you should declare "Location: Coarse Location" in your privacy label.
The Key: Mark it as "Not Linked to User" because Respectlytics processes IP transiently for the lookup and immediately discards itβno IP is ever stored. This keeps your label "clean" while being audit-proof.
3. Audit Your Privacy Manifest
Open your PrivacyInfo.xcprivacy file in Xcode. If your analytics SDK requires you to list APIs like NSPrivacyAccessedAPICategoryUserDefaults or NSPrivacyAccessedAPICategoryFileTimestamp, make sure you have valid reasons declared.
Respectlytics SDK: Our SDK source code is publicly viewable on GitHub so you can verify exactly what APIs we use and what data we send. We designed it to avoid "Required Reason APIs" wherever possible.
π What Respectlytics Actually Stores (5 Fields)
We believe in full transparency. Here's exactly what ends up in our database:
| Field | Purpose |
|---|---|
event_name |
The action you're tracking (e.g., "purchase", "signup") |
timestamp |
When it happened |
session_id |
Hashed with daily rotationβoriginal never stored |
platform |
iOS, Android, or web |
country |
Derived from IP, then IP discarded |
That's it. No device IDs. No user IDs. No crash logs. No IP addresses.
π― Summary: What This Means for You
You have two choices when submitting your app update:
The Hard Way
Spend hours mapping out which SDKs collect what, writing complex justifications in your Privacy Manifest, and displaying a long "Data Linked to You" label that may concern users.
The Easier Way
Use a privacy-first analytics tool that minimizes data collection by design. Check fewer boxes, pass App Review with less friction, and show users a cleaner privacy label.
By switching to Respectlytics, you're not just protecting your users' privacyβyou're simplifying your own workflow.
π Need the Exact Checkboxes?
For a detailed, step-by-step guide on exactly what to select in App Store Connect (and Google Play Data Safety), see our developer resource:
Privacy Disclosure Guide for App Stores βLegal Disclaimer: This information is provided for educational purposes and does not constitute legal advice. Privacy requirements and App Store policies change over time. Consult your legal team to determine the requirements that apply to your specific situation.