App Store privacy labels and the Google Play Data safety form, filled in for a typical Flutter app

You answer for every SDK in the build

Both forms ask about your app. That includes code you did not write.

Apple's App Privacy page says you need to identify all the data you or your third-party partners collect, and it names analytics tools, advertising networks and third-party SDKs as partners. Google's Data safety help page says the same about libraries and SDKs, and adds that you alone are responsible for complete and accurate declarations. Every app published on Google Play has to complete the form, even one that collects nothing, and a privacy policy link is required either way.

In a Flutter project this catches people out. A single plugin line in pubspec.yaml can pull in a native Firebase or Google SDK on both platforms. So before opening either form, I would list every plugin and the native SDKs it brings in, and check each one's own disclosure guidance. Firebase publishes that guidance for both stores, which is where most of the example below comes from.

The example app and what its SDKs collect

The app is ordinary: users sign up with email and password through Firebase Authentication, Google Analytics for Firebase records screens and sessions, Crashlytics reports crashes, and Firebase Cloud Messaging sends push notifications. No ads, no in-app purchases, no location permission.

Firebase's own pages say what each SDK collects. Authentication always collects identifiers for sign-in, and collects email address and a generated user ID when you use email login. Analytics collects an app-instance ID, a masked IP address used to derive coarse location, and screen view and session events; on Android it also collects the Advertising ID unless you turn that off. Crashlytics collects stack traces, app state and device and OS details at crash time, plus an installation UUID. Cloud Messaging on iOS collects the APNs token linked to an installation ID, plus device model, language, time zone, OS version and app version.

This is a worked example, not legal advice. Your answers change with your configuration, and Firebase's pages say so directly.

How I would fill in both forms for that app

The table maps each piece of data to Apple's data types and Google's categories. Apple asks whether each type is linked to the user and used for tracking. Google asks whether it is collected or shared, and why.

Linked, tracking and shared: the three answers people get wrong

Linked is the default. Apple treats data as linked to the user unless it is de-identified before collection, and you must not try to link it back afterwards. An app with accounts is usually linked across the board. If you call Crashlytics with a user ID, crash data is linked for certain.

Tracking is narrower than most people think. Apple defines it as linking data from your app with third-party data for targeted advertising or advertising measurement, or sharing it with a data broker. Analytics for your own product is not tracking on that definition. That answer changes if you turn on Google Ads linking or Google signals in Analytics, which Google's Analytics help page says can add collection or sharing.

Shared, on Google's form, has exceptions. Transfers to a service provider that processes data only on your behalf are not counted as sharing. My reading is that Firebase used this way falls under that exception, so the example answers collected but not shared. Check that against your own contracts and settings before you rely on it.

• Apple lets you skip a data type only when it meets every optional-disclosure condition, such as a one-off feedback form the user fills in each time. Ongoing collection after a permission prompt never qualifies.
• Google's form asks if data is encrypted in transit. Google's Analytics help page says the Analytics SDK sends its data over TLS; confirm the same for your own backend.
• Google's form asks how users can request deletion. An in-app option, a contact form or an email address all count.
• Google lets you mark data as optional only if every user can decline it and still use the app's core features.

Privacy manifests on iOS

Apple also wants a privacy manifest from many common SDKs. Its third-party SDK requirements page lists FirebaseAuth, FirebaseCore, FirebaseCrashlytics, FirebaseMessaging and Flutter itself, along with plugins such as flutter_local_notifications, path_provider and url_launcher. You must include the manifest for a listed SDK when you submit a new app that uses it, or an update that adds it. Listed SDKs used as binary dependencies also need a signature.

In practice that means keeping Flutter and the plugins current, since the manifests ship with the SDKs. A manifest does not fill in your labels for you. Firebase's Apple page says its manifests cover data that is always collected or collected by default, and that keeping your labels accurate is your job. Its own example: if you store push tokens in Firestore, you may need to declare identifiers that the Firestore manifest does not list.

Apple lets you change your App Privacy answers at any time without shipping a new build. Google asks you to update Data safety whenever your practices change, and says misrepresentation can lead to blocked updates or removal. I would review both every time a new SDK goes in.

Where this sits in my packages

Every package includes help with store submission, and both forms are part of a submission. Launch ($999) includes sign-up and login, so the email and user ID rows apply from day one. Growth ($1,699) adds your own Node.js backend and PostgreSQL database, which means your server's data handling has to match the answers too. Scale ($2,500) includes push notifications where supported, which brings the push token row in.

I can map what the app's code and SDKs collect into both forms with you. Your privacy policy is a legal document, so have a lawyer review it. Specialised compliance work is quoted separately, and approval stays Apple's and Google's decision.