Filling in Google Play Data safety and Apple App Privacy for a small app

Both app stores show a privacy summary on every listing. On Google Play it’s the Data safety section, and on the App Store it’s App Privacy. You write both, the stores display them as fact, and you stay responsible for them being accurate. For a small app or game, the hard part is rarely your own code. It’s the advertising, analytics and crash-reporting libraries that send data on your behalf. This guide walks through both forms, what an ads SDK adds to your answers, Apple’s privacy manifest rule for third-party code, and the account deletion requirements on each store. The rules come from Google’s and Apple’s developer documentation, checked on 29 October 2026.

Both forms are about data that leaves the device

Google defines “collect” as transmitting data from your app off a user’s device. That includes data sent by libraries and SDKs in your app, and data from a webview your app controls. “Sharing” means transferring user data to a third party. Sending data to a service provider that processes it on your behalf doesn’t count as sharing.

Apple’s definition is close. “Collect” means transmitting data off the device in a way that lets you or your third-party partners access it for longer than is needed to service the request in real time.

Both definitions turn on the same question: does the data leave the phone? Google says outright that data processed only on the device, and never sent off it, doesn’t need to be declared as collected.

Start with an inventory, not the form

The forms ask about data types, purposes and whether data is linked to a person. You can’t answer them well from memory. Before opening either console, make a list:

1. Write down every SDK and service in the app: ads, analytics, crash reporting, sign-in, payments, remote configuration and anything that loads a webview.
2. For each one, note what it sends, why, and whether it carries an identifier.
3. Fill in both forms from that list, not from memory.

Most large SDK providers publish their own disclosure guide for exactly this purpose. Google’s Data safety page points developers to the Google Play SDK Index to find that guidance. Read the guide for the version you actually ship, because SDKs change what they collect between versions.

Both stores are clear about who’s accountable. Google says you must declare data collected or shared by third-party code in your app and that you alone are responsible for complete and accurate answers. Apple says you must identify all the data you or your third-party partners collect. Apple makes one exception: you aren’t responsible for disclosing data that Apple itself collects through its own frameworks.

What an ads SDK adds to your answers

The games I make at Matterward Labs carry optional rewarded ads, which I wrote about in rewarded ads in free games. Ads are the most common reason a simple game ends up with a longer privacy label than its developer expects.

Google’s disclosure guide for the Google Mobile Ads SDK on Android lists what the SDK collects and shares automatically, for advertising, analytics and fraud prevention:

• the device’s IP address, which may be used to estimate the device’s general location
• user product interactions, such as app launches, taps and video views
• diagnostic information about app and SDK performance, such as launch time, hang rate and energy usage
• device and account identifiers, such as the Android advertising ID and app set ID

The same guide says the data is encrypted in transit, and that collecting the Android advertising ID is optional and can be turned off in the app’s manifest. It also notes that optional features may need extra disclosures.

The iOS guide lists a similar set: IP address, crash logs, performance data, device identifiers, advertising data and product interactions. It notes that device identifiers may be used for third-party advertising and analytics, which matters for Apple’s tracking question below. Recent versions of the iOS SDK support privacy manifest declarations, and if you use mediation, Google advises checking that each adapter’s version supports them too.

Apple’s extra questions: linked data and tracking

Apple asks two questions Google doesn’t frame the same way.

The first is whether data is linked to the user. Apple says collected data is often linked to a person’s identity unless privacy protections are applied before collection to de-identify it, and that personal data as defined in privacy law counts as linked.

The second is tracking. Apple defines tracking as linking data from your app about a particular user or device with third-party data for targeted advertising or advertising measurement, or sharing that data with a data broker. Since iOS 14.5, you need the person’s permission through the App Tracking Transparency (ATT) framework to track them or to read the device’s advertising identifier. Without that permission, the identifier comes back as all zeros.

Some data is optional to disclose, but only if it meets every one of Apple’s conditions: it isn’t used for tracking or advertising, it’s collected only occasionally and optionally outside the app’s main purpose, and the person knowingly provides it each time. Data an ads SDK collects in the background won’t meet those conditions.

Privacy manifests for third-party code

Apple uses privacy manifest files to describe the privacy practices of third-party code in a single standard format. Apple keeps a list of commonly used SDKs. If a new app includes one of them, or an update adds one, the submission must include that SDK’s privacy manifest. When a listed SDK is included as a binary dependency, it also needs a signature. The rule covers every version of a listed SDK and any SDK that repackages one.

For a small team, the practical upshot is to keep SDKs reasonably current, because older versions may not ship a manifest, and to check each provider’s release notes for privacy changes when you update.

Google’s security and deletion questions

The Data safety form also asks about security practices. You’re asked whether all the user data your app collects is encrypted in transit, and whether people can ask for their data to be deleted.

Google doesn’t prescribe how deletion requests should work. An in-app option, a contact form or a dedicated email address can all count, as long as people can find it. You can also say you offer deletion if you automatically delete or anonymise data within 90 days of collecting it.

Two points surprise first-time publishers. Even an app that collects no user data must complete the form and provide a link to a privacy policy. And the form applies to apps on closed and open testing tracks as well as production. Only apps used solely on internal testing tracks are exempt. If you’re publishing from a new personal account, you’ll meet the form during the closed testing requirement.

Account deletion on both stores

If people can create an account from within your app, Google requires two things: an in-app path to delete the account and its data, and a web link where people can request deletion of their account. That link goes into the Data safety form. Deleting the account means deleting the user data associated with it too. If you have to keep some data, for security or legal reasons for example, you must tell people what you keep, such as in your privacy policy.

Apple’s rule is App Review Guideline 5.1.1(v), explained in its guide to offering account deletion. Apps that support account creation must let people start deleting their account from inside the app. Apple expects the whole account record and its personal data to go, including content the person shared with others. Offering only to deactivate or disable the account isn’t enough. Guest accounts that the app creates automatically are included.

If people have to finish the process on a website, the app must link straight to that page. A manual process that takes some time is acceptable, as long as you say how long it will take and confirm when it’s done. Apps outside highly regulated industries shouldn’t make people phone, email or chat with support to delete an account. If you offer Sign in with Apple, Apple asks you to revoke the user’s tokens through its REST API.

Keep the answers true after launch

Privacy labels go stale quietly. A new SDK, an updated SDK or a new analytics event can change your answers without changing anything a person sees in the app. Apple says you can update your App Privacy answers at any time without submitting an app update. Google says misrepresenting your data practices can lead to enforcement, such as blocked updates or removal.

The habit that works is simple: whenever you add or update an SDK, reread its disclosure guide and your two forms in the same sitting. A privacy label is part of the store listing, read by the same people who look at your screenshots, so it deserves the same care. The two free games on the games page both carry optional ads, which is exactly the situation where an out-of-date SDK can make the label wrong without anyone noticing.