US | Store compliance | 2026-09-06

App Privacy Labels and Data Safety Forms: Filling Them Out Without Guessing

Both stores make you declare what your app collects before you can publish. The declarations are visible to every user and checked against your actual code. Here is how to fill them out truthfully the first time.

Somewhere in the last stretch before your first submission, both app stores stop asking about your app and start asking about your users' data. Apple calls it App Privacy, and the result is the "nutrition label" that appears on your App Store listing. Google calls it Data safety, and it shows up on your Play listing as a card that users can expand. Both are mandatory. Both are public. And both are surprisingly easy to fill out wrong, because the forms ask questions that most founders have never had to answer about their own product.

This guide walks through what the forms actually ask, how to figure out the honest answers for a typical small-business app, and the handful of mistakes that lead to rejections, delistings, or a label that quietly scares users away. It is written for founders commissioning an app, not for lawyers, and it does not replace legal advice on your specific situation.

What the two forms have in common

Under the different vocabulary, Apple and Google are asking the same three things about every category of data your app touches.

• Do you collect it? Collection means the data leaves the device and goes to you or to a third party you have integrated, like an analytics or crash-reporting service. Data that stays on the phone and never gets sent anywhere generally does not count.
• Is it linked to the user? Can it be tied back to a specific person, through an account, a device identifier, or a combination of fields? An email address is linked. Anonymous aggregate usage counts usually are not.
• What do you use it for? App functionality, analytics, personalization, advertising, and so on. Google also asks whether the data is shared with third parties and whether the user can request deletion.

The trap is that "you" includes every SDK in your app. If your app ships with a crash reporter, an analytics tool, a push notification service, an ad network, or a payment provider, each of those collects something, and you are responsible for declaring it. Both stores are explicit about this, and both have tooling that checks your binary against your answers.

Start with an inventory, not the form

Do not open the store form first. Open a spreadsheet, and list every piece of data the app handles. For most small-business apps that list is shorter than it sounds. A typical inventory looks like this.

• Account: email, name, maybe a phone number. Collected, linked, used for app functionality.
• Payment: handled by Stripe or the store's own billing, so your app never sees the card. You still typically declare purchase history if you store it.
• Usage: which screens are opened, how long sessions last. Collected by your analytics SDK, often linked via a device or user identifier.
• Crash data: stack traces and device model from your crash reporter. Collected, usually not linked to identity, used for app functionality.
• Location: only if the app actually requests it. If you show a map of your store, that is not collection. If you record where the user is, it is.
• Photos or camera: only if the app uploads them. A profile photo the user picks is collected user content.
• Identifiers: user ID, device ID, advertising ID if you use ads.

For each row, note which SDK or backend touches it. That column is what lets you answer the "third party" questions accurately, and it is the first thing to ask your developer for. We covered which analytics to install before launch in a separate guide, and that setup determines a large share of what your label will say.

Apple: the App Privacy section

Apple's form lives in App Store Connect and asks you to go category by category through data types: contact info, health, financial, location, sensitive info, contacts, user content, browsing history, search history, identifiers, purchases, usage data, diagnostics, and a few others. For each one you collect, you say whether it is linked to the user, whether it is used for tracking, and what purposes it serves.

"Tracking" has a specific meaning at Apple. It refers to linking user or device data collected from your app with data from other companies' apps and websites for advertising or measurement, or sharing it with a data broker. If you show ads from a third-party network, you are almost certainly tracking and will also need to use the App Tracking Transparency prompt. If you do not run ads and do not share data with brokers, most small-business apps are not tracking, and you should answer accordingly.

The label is generated from your answers and displayed on your listing. Apple can and does review apps whose labels appear inconsistent with the binary's behavior. An SDK that collects the advertising identifier while your label says "Data Not Collected" is a common reason for a rejection during review.

Google: the Data safety section

Google's form is in the Play Console and covers similar ground with slightly different categories, plus a few extra questions: whether data is encrypted in transit, whether users can request deletion, whether the app follows the Families policy, and whether it has an independent security review. It also asks separately about data collection and data sharing, where sharing means transferring to a third party for that party's own purposes.

Google publishes guidance for common SDKs, and many SDK vendors publish their own Data safety declarations. Use them. If your app includes a crash reporter, that vendor's documentation will tell you exactly which boxes to tick for their component. Combine those with your own backend's behavior and you have the form.

Google also requires a privacy policy URL for every app that collects data, and the policy has to be reachable from both the store listing and inside the app. The policy and the Data safety form must agree with each other. A policy that says you never collect location while your form says you do is a policy violation, and Google's enforcement on this has tightened considerably.

The mistakes that cause rejections

Having shipped a number of these, the errors we see repeat.

• Forgetting the SDKs. The founder answers for their own code and forgets that the analytics library collects device identifiers and usage data. This is the single most common mismatch.
• Declaring "no data collected" to look good. A clean label is attractive, but a false one is a rejection or a later delisting. If you collect an email for login, say so. Users are not scared by "email address, used for account functionality." They are scared by vague or suspicious labels.
• Over-declaring. The opposite error. Founders sometimes tick every box to be safe. The result is a label that says you collect health data and precise location for an app that sells lawn care. That drives users away and can trigger review questions.
• Privacy policy drift. The policy was written for version one, the app added a feature in version three, and nobody updated either the policy or the form.
• Copying another app's answers. Two apps with different SDKs and backends have different labels, even if they look similar to users.

Handle it before submission, not after

The forms can be edited later, but the first submission is when they are checked most carefully, and a mismatch there costs you a review cycle. Our guide on app store review rejections covers the broader list, and privacy declarations are near the top of it for first-time submissions.

The practical order is: finalize the SDK list, build the data inventory, write or update the privacy policy to match, fill out Apple's form, fill out Google's form, and then have someone who was not involved read the label on a test listing and tell you whether it makes sense for the app they see. If the label makes a plumber's booking app look like a surveillance tool, something is wrong in the inventory.

What handoff should include

If a studio is building the app for you, the privacy declarations are part of the deliverable. Ask for the data inventory as a document, the list of every SDK and what it collects, the privacy policy text, and the exact answers submitted to both stores. That package is what lets you update the forms yourself when the app changes, and it is the kind of thing that should be in the handoff alongside the source code and store accounts.

Privacy labels are not a marketing exercise and they are not a legal trap. They are an inventory of what your app does with people's information, written in a format both stores can check. Do the inventory honestly, keep it current, and the forms take an afternoon. Skip it, and it becomes the reason your launch slips a week. If you want an opinion on what a specific app will need to declare, get in touch, or read more launch guides on the blog.