Privacy requirements on Google Play and the App Store — Data safety, privacy manifests and account deletion

In many companies, the data form on Google Play and the privacy labels on the App Store were filled in once — in 2021 or 2022, when the stores started requiring them — and nobody went back to them. Since then the app has gained new features, analytics, chat, ads, crash reporting. The store declarations describe an app that no longer exists.

As long as nobody checks, nothing happens. But the stores check more and more thoroughly: they analyse which libraries the app contains, which permissions it uses and where it sends data. The result of a mismatch is a rejected update at the worst possible moment, an email with a deadline for fixes, or the app being removed from the store.

This article brings together the privacy requirements of both stores that most often cause trouble for owners of existing apps, and explains how to put them in order.

Requirements at a glance

The Data safety form on Google Play

In the Data safety section you declare which data the app collects (sends off the phone) and shares (passes on to other companies), for what purpose, whether it's mandatory and how it's protected. Every app has to fill in the form — including one that collects no data at all.

The most common mistakes we see in existing apps:

• Third-party libraries left out. The declaration covers data collected by every SDK in the app, not just your own code. Firebase Analytics, Crashlytics, the Facebook SDK, ad libraries and chat widgets collect device identifiers, app usage data or crash logs. If the form says "no data collected" and the app has analytics, the declaration is false.
• The form not updated after changes. Added location, a new contact form, a payment integration — any of these may require the declaration to be updated.
• "Collecting" confused with "sharing". Passing data to a service provider that processes it on your behalf (such as hosting or crash reporting) usually isn't sharing in Google's sense — but passing it to an ad network is.
• Inconsistency with the privacy policy. Google compares the declarations with the privacy policy and with what the app actually does. A discrepancy is a policy violation.

Providers of popular SDKs publish descriptions of the data their libraries collect, specifically with this form in mind. Start with a list of every library in the app and check each one.

Privacy labels and tracking consent on the App Store

The App Store requires a similar declaration in App Store Connect (App Privacy). It appears on the app's store page as a privacy label: data linked to the user, data used to track the user and data not linked to their identity. The principle is the same as on Google Play — the declaration covers third-party libraries too.

A separate requirement is App Tracking Transparency (ATT). If the app combines data about the user with data from other apps or websites for advertising, or passes it to data brokers, it has to ask for permission first through the system prompt. This also applies to ad libraries and some marketing tools that do it "quietly". Tracking without consent is a common reason for rejection.

Privacy manifests and required reason APIs (iOS)

Since May 2024, Apple has required apps and third-party libraries to include a privacy manifest file (PrivacyInfo.xcprivacy). It describes what data the code collects and — the part that causes the most trouble — why it uses so-called required reason APIs. These are ordinary system functions, such as UserDefaults, reading a file's modification date, system uptime or free disk space. Apple requires a reason because they can be used to build a device "fingerprint".

In practice, the problem looks like this: the app hasn't been updated for a while, someone uploads a small fix, and Apple replies with an email containing error ITMS-91053 ("Missing API declaration") or a notice about a library without the required manifest or signature. Popular libraries — including Firebase and many Flutter plugins and React Native modules — only include manifests in newer versions.

The fix has two parts: adding your own manifest with declarations for the app's code, and updating libraries to versions that ship their own manifests. The second part can be harder, because newer library versions often require a newer framework. If your app is built with Flutter or React Native and hasn't been updated in years, see our article on updating an old app.

Account deletion: a requirement in both stores

If users can create an account in the app, both stores require that they can also delete it. This is one of the requirements that most often surprises owners of older apps, because it involves not just a screen in the app but the backend too.

App Store (since June 2022):

• account deletion must be initiated in the app, somewhere easy to find, such as account settings,
• deletion must mean deleting the account and its data, not just deactivating it,
• if the app uses Sign in with Apple, the tokens have to be revoked through Apple's API when the account is deleted,
• in regulated industries an extra step is allowed, such as confirmation via customer service — but the process has to start in the app.

Google Play (since December 2023, with extensions to May 2024):

• account deletion must be available in the app,
• you also need a web page where users can request account deletion without installing the app — its URL is entered in the Data safety form,
• data linked to the account has to be deleted; if you need to keep some of it longer (invoices for tax purposes, for example), that has to be disclosed.

On the technical side this usually means: a screen in the app with a confirmation step, a server endpoint that actually deletes or anonymises data everywhere it lives (database, files, third-party services, mailing systems), a web page with a form, and a documented procedure. It also puts in order how you handle the GDPR right to erasure, which you have to support anyway.

Sensitive permissions on Google Play

Google Play restricts access to some permissions and requires a justification in Play Console. This covers, among others, background location, SMS and call log access, the list of installed apps and — more recently — broad access to photos and videos. Apps that only need photos occasionally (to add an avatar, for example) are expected to use the system photo picker instead of requesting access to the whole gallery.

Older apps often declare permissions in their manifest that nobody uses any more — added at some point by a library or by a feature that has since been removed. Every such permission is a potential problem in review. The simplest fix: remove unused permissions, and for the rest prepare a justification that matches how the app actually works. An app that uses the advertising ID and targets Android 13 or later also has to declare the AD_ID permission explicitly.

Privacy policy

Both stores require a link to a privacy policy, and its content has to match what you declare in the forms and what the app actually does. Typical problems:

• a policy written for the website that doesn't mention the app, its permissions or its libraries,
• a store link pointing to a page that no longer exists (after a domain change or a site rebuild, for example),
• no information about account and data deletion.

A privacy policy is a legal document, so its content is worth reviewing with a lawyer. The technical team's role is to provide an accurate list: what data the app collects, through which libraries, where it sends it and how long it keeps it.

How to run a compliance review

1. List the app's libraries (Android, iOS and — in cross-platform apps — plugins) and check what data each one collects.
2. Check the permissions in the Android manifest and the permission descriptions on iOS. Remove unused ones.
3. Inspect the network traffic of the built app: where it sends data and what data. This is the most reliable way to catch libraries nobody remembered.
4. Compare the results with the declarations in Data safety, App Privacy and the privacy policy. Note every discrepancy.
5. Check account deletion — whether it's in the app, whether the web page works, and whether data is really deleted from the backend and third-party services.
6. Update libraries to versions with privacy manifests and prepare your own manifest.
7. Fix the declarations and the policy, then release an update.
8. Build it into your release process. Every new library or new type of data is a checkpoint: do the forms need to change? It's easiest to remember when it's part of your mobile app maintenance contract.

How long it takes

Summary

Privacy requirements on Google Play and the App Store aren't a one-off form, but a description of the app that has to keep up with its changes. Older apps most often lack account deletion, a privacy manifest and up-to-date declarations covering every library. Each of these can block an urgent update and, in the worst case, lead to the app being removed from the store. If the store has already rejected a build, see also what to do step by step after an app rejection.

If you're not sure whether your app's declarations are up to date, request a free app analysis — we'll check its libraries, permissions and both stores' requirements. We keep apps in line with changes to Google's and Apple's policies as part of our mobile app maintenance service.