How to fill in Google Play's Data safety form and Apple's App Privacy details

Make one list of what your app sends off the device, SDKs included, and answer both questionnaires from it. Google Play’s Data safety form and Apple’s App Privacy details ask about the same facts in different words. When your answers come from two separate memories, they drift apart.

Every app on Google Play must complete the Data safety form, including an app that collects nothing. Only apps that are live on internal testing tracks are exempt (Google Play’s Data safety help). Apple asks for App Privacy details for every app on the App Store (Apple’s App Privacy details).

Where the forms are

• Google Play: Play Console → your app → App content → Data safety.
• App Store: App Store Connect → your app → App Privacy.

Step 1: build the list

1. Every third-party SDK. Read your dependency files: build.gradle / libs.versions.toml, Podfile / Package.swift, pubspec.yaml, package.json. Both stores count what an SDK collects as yours. Apple holds you responsible for all code in your app, including code you did not write.
2. What each one sends. Use the vendor’s own page. Some vendors publish their answers in Play’s own vocabulary, including RevenueCat, Unity Ads and OneSignal. Google publishes tables for AdMob and for each Firebase product. On iOS, most current SDKs ship a privacy manifest (PrivacyInfo.xcprivacy). In Xcode, open Organizer, right-click an archive and choose Generate Privacy Report to see every manifest in your build on one page (Apple’s privacy manifest documentation).
3. Your own collection. Accounts (email, user id), anything your backend stores, location your own code reads, purchase records your server keeps.

Some vendors publish nothing. AppLovin has no data-type list for either store, and several analytics SDKs have no Play mapping. For those, read the SDK’s own documentation on what it transmits and write the gap down. Do not guess.

Step 2: Google Play’s questions

For each data type, Play asks:

• Collected, shared, or both? “Collected” means sent off the device. “Shared” means sent to a third party. A service provider that processes data on your behalf does not count as sharing, and neither does fully anonymised data. This is why Firebase Analytics is usually “collected, not shared” and an ad SDK is usually “collected and shared”.
• Processed ephemerally? Only if the data is held in memory just long enough to serve that one request, such as a location sent to fetch the weather and not stored.
• Required or optional? Optional means the user can choose whether it is collected.
• Why? Play’s purposes are: App functionality, Analytics, Developer communications, Advertising or marketing, Fraud prevention, security, and compliance, Personalization, Account management. Collection and sharing each get their own purposes.

Then two security questions. Is all user data encrypted in transit? Only you can check that. One plain http:// endpoint makes the answer No. Can users request deletion? You can answer Yes if you offer a way to request it, or if you delete the data automatically within 90 days.

If your app lets users create accounts, the Data deletion questions in the same form also ask for a web link where users can request account deletion (Google Play’s account deletion requirements). See the account deletion URL guide.

Payment details entered in Google Play’s own billing sheet do not need declaring as long as your app never accesses them. Purchase records your app or an SDK receives are still yours to declare.

Step 3: Apple’s questions

For each data type, Apple asks the purpose and two yes/no questions:

• Linked to the user? Data counts as linked unless it is de-identified before it is collected. An account, a user id or a device id is enough to link it.
• Used for tracking? Tracking means combining your app’s data about a user or device with other companies’ data for targeted ads or ad measurement, or sharing it with a data broker. An SDK can do this even if you never use that feature. If anything is used for tracking, the app must ask permission through App Tracking Transparency first (Apple’s user privacy and data use).

Apple’s purposes are: Third-Party Advertising, Developer’s Advertising or Marketing, Analytics, Product Personalization, App Functionality, Other Purposes.

Apple lets you leave a data type out only when every one of four conditions holds. It must not be used for tracking or advertising. It must be collected only rarely, outside the app’s main function, and at the user’s option. And the user must provide it knowingly each time. Most SDK data fails the first condition.

The three answers people get wrong

1. “We collect nothing.” Crash reporters and analytics send device identifiers and diagnostics, even when your own code sends nothing.
2. “Not shared” for an ad SDK. Ad networks receive identifiers and interactions for their own advertising purposes. That is sharing.
3. A form that disagrees with the privacy policy. The stores read the two together, so a disagreement is enough on its own. Write both from the same list. See when the two disagree.

Keeping it current

The answers are only as current as your SDK list. When you add an SDK, update both forms and your privacy policy in the same change. Vendors revise their disclosures with new SDK versions too.

Let an AI assistant find the SDKs

The slow part is step 1, and a coding agent opened in your app’s repository can do it for you: Claude Code, Cursor, Codex and the like. The prompt below asks it to read only your build files and name every SDK and data fact with the file it came from. It does not ask what each SDK collects. A model’s memory of a vendor’s disclosure is a guess, and that part should come from the vendor.

It replies in a small JSON format that the AppFoyer dashboard reads. Without AppFoyer, the list it shows you in step 2 is still the one to fill both forms from.

You are helping me fill in Google Play's Data safety form and Apple's App Privacy details for my mobile app. AppFoyer turns your answer into draft answers for both forms, using each SDK vendor's own published disclosure. Your job is only to find what is in the build — not to say what any SDK collects.

## About the app

- App name: [app name]
- Platforms: [Android, iOS or both]

## Step 1 — read the build files

Read only the app's build, manifest and store-metadata files — for example `build.gradle(.kts)`, `gradle/libs.versions.toml`, `AndroidManifest.xml`, `Podfile.lock`, `Package.swift`, `Package.resolved`, `Info.plist`, `*.entitlements`, `PrivacyInfo.xcprivacy`, `pubspec.yaml`, `package.json`, `app.json`. Do not open `.env` files, keystores, credentials or any other secrets, and do not change any file. If you cannot read the code, ask me which SDKs the app uses instead.

Find:

1. Every third-party SDK in the build. Match it to one of these ids where it fits:

- `admob` — Google Mobile Ads (AdMob)
- `applovin-max` — AppLovin MAX
- `unity-ads` — Unity Ads
- `firebase-analytics` — Google Analytics for Firebase
- `mixpanel` — Mixpanel
- `amplitude` — Amplitude
- `meta-app-events` — Meta SDK — App Events
- `firebase-crashlytics` — Firebase Crashlytics
- `sentry` — Sentry
- `firebase-auth` — Firebase Authentication
- `google-sign-in` — Google Sign-In
- `meta-login` — Meta SDK — Facebook Login
- `revenuecat` — RevenueCat
- `firebase-messaging` — Firebase Cloud Messaging
- `onesignal` — OneSignal

   An SDK that fits none of them goes under `otherSdks` with its package name. Never force a match.

2. Which of these facts are true, from the dependencies, permissions and usage-description keys:

- `account` — users sign in or create accounts
- `analytics` — usage analytics
- `ads` — advertising
- `crash` — crash reporting or diagnostics
- `location` — the app reads the device location
- `purchases` — in-app purchases or subscriptions

   If none is true, the facts are `["none"]`.

Keep the file, and the line where you can, for every SDK and every fact. A README sentence is not evidence.

## Step 2 — confirm with me

Show me the list, grouped as SDKs, other SDKs and facts, each with its file. Ask me to confirm or correct it, and to add anything the build files cannot show — for example an SDK loaded at runtime. Wait for my answer.

## Step 3 — reply in AppFoyer's format

Reply with one ```json code block and nothing after it, exactly in this shape:

```json
{
  "format": "appfoyer-store-forms/1",
  "platform": "android | ios | both",
  "sdks": [{ "id": "admob", "file": "app/build.gradle.kts", "line": 42 }],
  "otherSdks": [{ "name": "com.example:tracker", "file": "app/build.gradle.kts", "line": 57 }],
  "facts": [{ "fact": "ads", "file": "app/src/main/AndroidManifest.xml", "line": 12 }]
}
```

- `id` is one of the ids above, spelled exactly. `fact` is one of the facts above, or `none`.
- `line` is a number, or leave it out when you do not know it.
- Empty lists are `[]`. No comments inside the JSON.
- Do not describe what an SDK collects, and do not add fields.

With AppFoyer

Each app in the dashboard has a Store forms tab. Tick the SDKs your build includes, and it drafts the Data safety and App Privacy answers from them and your app’s settings. Every answer names its source: the vendor’s own answers, its privacy manifest, or our reading of its data list. The tab flags an SDK your privacy policy does not mention, and gives you the account deletion link to paste. The Claude Code plugin fills in the SDK list from your build files. With another assistant, copy the prompt from the tab, run it, and paste the reply back: the tab shows the answers it implies before anything is saved. You still enter the answers in each console and check them there. They are drafts, not legal advice. The tab is free on every plan.