An app can be ready to publish and still fail its privacy review because its features, privacy policy and store declarations do not match. Use this checklist to audit the data your app handles, complete Apple and Google’s forms accurately, and keep every disclosure aligned.
The privacy test your app must pass
Imagine a fitness coach app with member accounts, optional location, an email form and analytics. That is already four separate data paths. Change one feature and the privacy picture changes with it.
The difficult part is not producing one legal page. It is making three surfaces describe the same app:
| Surface | What it must reflect |
|---|---|
| The app itself | The data, permissions and third-party services actually used |
| The privacy policy | What is collected, why, by whom, for how long and what users can do about it |
| The store declarations | Apple App Privacy and Google Play Data safety answers based on the current app |
If one surface says “no location data” while the submitted app requests location access, the problem is inconsistency.
A large part of privacy preparation is a consistency exercise: the app, the policy and the store listing must tell the same story. Consistency is necessary, but it does not replace compliance with the stores’ underlying privacy and user-data rules.
This article helps you prepare that story. It is not legal advice; applicable requirements vary by country, audience and type of data.
1. Inventory every place where data enters or leaves the app
Start with the app you are about to submit, not the app in your original brief. Open each feature and follow what a user can actually do.
For every data path, record:
- the type of data involved, such as an email address, location, photo, device identifier or app activity;
- whether providing it is required or optional;
- why it is collected or used;
- whether it can be linked to a person or account;
- whether a third party receives or processes it;
- how long it is retained and how it can be deleted.
Then check the less obvious paths: analytics, advertising, social login, embedded websites, forms, custom code and external services. Do not treat permissions and data collection as synonyms. A permission controls access to a device capability; the store forms ask what happens to data.
For a GoodBarber app, the Privacy Center gives you a practical starting point by inventorying the permissions required by the features you activated. Your own use of forms, external web pages, plugins and custom integrations still needs a manual check: only you know what information you ask users to provide and what you do with it.
2. Publish a privacy policy that describes this exact app
A generic website privacy policy is rarely enough. Your app may use device permissions, accounts, uploads or services that do not exist on your website.
Apple’s App Review Guidelines require a privacy policy link in App Store Connect and inside the app. The policy must explain what data is collected, how it is used, which third parties can access it, how long it is retained and how users can revoke consent or request deletion. Google Play’s User Data policy also requires a privacy policy in Play Console and within the app.
Before submission, verify that the policy:
- names the app or the legal entity shown on its store listing;
- identifies the data the app accesses, collects, uses and shares;
- explains the purpose of each use in plain language;
- identifies relevant third-party services or categories of recipients;
- describes secure data-handling procedures for personal and sensitive user data;
- explains retention and deletion;
- provides a working privacy contact;
- for Google Play, is hosted at an active, publicly accessible and non-geofenced URL, is non-editable, is not a PDF, and is easy to find inside the app.
A template is a starting point. Delete clauses that do not apply and add the data paths that do. GoodBarber provides a privacy-policy template based on the app’s configuration; the app owner remains responsible for the final text.
3. Complete Apple App Privacy from the current configuration
Apple’s privacy label is a structured summary displayed on the App Store product page. It is not the privacy policy copied into another field.
In App Store Connect, you first declare whether the app or its third-party partners collect data. For every applicable data type, Apple then asks why it is collected, whether it is linked to the user and whether it is used for tracking. Apple explicitly requires you to include the practices of third-party partners whose code is integrated into the app and to keep the answers accurate as those practices change.
Work from your inventory. Location, accounts, uploads, advertising and analytics can all change the answers. Do not copy a declaration from another app.
GoodBarber users can follow the current, field-by-field guide to complete the App Privacy form in App Store Connect. The guide distinguishes the declarations that apply by default from those that depend on enabled permissions and extensions.
Do not confuse the App Privacy label with Apple’s privacy manifests. A privacy manifest records the categories of data collected by an app or third-party SDK and the approved reasons for using covered required-reason APIs. Apple also requires certain commonly used third-party SDKs to include valid privacy manifests and signatures. On GoodBarber, the native compilation layer handles the code and libraries in the binary; your job is to make the store answers reflect the configuration you chose.
4. Complete Google Play Data safety separately
Google Play’s Data safety section also explains what the app collects or shares and why. But it uses Google’s own definitions and questionnaire, so an Apple declaration is useful preparation, not a form you can paste unchanged.
For a standard Google Play publication, you must complete the Data safety form even if your app collects no user data. You must also provide a privacy policy. The declaration must cover data handled through third-party libraries and SDKs.
For each data type, check whether it is collected, shared or both; whether processing is temporary; whether users can choose; and the purpose. Then compare the completed form with the privacy policy. Google states that discrepancies between app behavior and the declaration can lead to enforcement.
GoodBarber’s Google Play Data safety guide maps the form to the platform’s default behavior and to features such as location, accounts and user uploads. It also draws the important boundary: GoodBarber cannot know how you use additional information collected through a form, an external website, a plugin or another custom path. Add those uses yourself.
5. Test account deletion, consent and permission flows
Privacy information is not complete if users cannot exercise the choices it describes.
If your app supports account creation, Apple requires users to be able to initiate account deletion from within the app. For Google Play, apps that allow account creation from within the app must provide both a readily discoverable in-app deletion path and an external web resource where users can request deletion of the account and associated data. Test both paths with a real account before submission, and make sure the policy explains any data you must retain.
Consent and device permissions need the same practical test. Ask only for access the enabled feature needs. Make the purpose clear when permission is requested, and provide any prominent in-app disclosure required by the store before the system permission prompt. If a service requires consent in your target market, verify that refusing or withdrawing it produces the behavior described in your policy. The goal is to make every request expected, necessary and understandable.
6. Run the final consistency check
Do this after the app configuration is frozen and before you submit the build.
| Check | App | Privacy policy | Store declarations |
|---|---|---|---|
| Accounts | Registration and deletion both work | Account data, retention and deletion are explained | Account-related data and deletion answers are complete |
| Location | Access is requested only when needed | Purpose and handling are explained | Location types match the enabled feature |
| Forms and uploads | Every field and media type is inventoried | Uses and retention are covered | Personal info, photos, videos or files are declared where applicable |
| Analytics and advertising | Only intended services are active | Third parties and purposes are disclosed | Identifiers, usage data and tracking answers match |
| External or custom features | Web views, plugins and custom code are reviewed | Additional collection is included | Additional data paths are declared |
Open every policy and deletion URL from a private browser window. Check the final build, not only the back office. If reviewers need an account to reach restricted content, provide working credentials in the submission notes.
How GoodBarber’s Privacy Center makes the checklist manageable
The GoodBarber Privacy Center brings the moving parts into one place: permission inventory, consent settings, privacy contacts, and terms and privacy-policy content.
The app configuration and the binary stay connected. Third-party libraries are integrated on demand when the corresponding feature is enabled; disable the feature and the related library is removed at recompilation. The default posture is to request only the permissions the app needs.
That makes the first part of this checklist visible. You can see whether location, camera or advertising-related access is enabled, then use GoodBarber’s publication guides to carry those choices into both store consoles.
No platform can infer the purpose of a custom form, the data collected by an external page or the retention rule applied outside the app. The Privacy Center organizes the platform side. You complete the business side. Explore the full privacy architecture to see how permissions, libraries and store preparation fit together.
And if you prefer to delegate the publication process, the GoodBarber Takes Care (GBTC) service can complete the App Store and Google Play data-use questionnaires for you, using your app configuration and the additional information you provide.
The goal is not to automate responsibility away. It is to make accurate privacy work possible without reverse-engineering your own app.
Privacy is part of every app update
Your declarations are not finished when the first version is approved. Review them whenever you add or remove accounts, location, uploads, analytics, advertising, payments, custom code or an external service. The same applies if you change why data is used, who receives it, how long you keep it or how users delete it.
Start with one concrete action: open your app’s Privacy Center and inventory every enabled permission and external service. Then compare that list with your policy, Apple’s App Privacy form and Google Play Data safety. Three surfaces. One accurate story.
Mobile app privacy checklist FAQ
Does every app submitted to the App Store or Google Play need a privacy policy?
Yes. Apple requires a policy URL for all apps and a link inside the app. Google Play requires a policy in Play Console and within the app, including when no user data is collected.
Can I use the same privacy policy for Apple and Google Play?
Yes, if it accurately covers the app and satisfies both stores. The questionnaires remain separate: Apple App Privacy and Google Play Data safety use different structures and definitions.
Can GoodBarber complete the store privacy questionnaires for me?
Yes. With the GoodBarber Takes Care (GBTC) service, our team can complete the App Store and Google Play data-use questionnaires based on your app configuration and the additional information you provide. You remain responsible for providing an accurate privacy policy and disclosing any additional data uses related to forms, external pages, plugins or custom integrations.