Mobile App Privacy Policy: What Must Match Before Launch

What Apple and Google expect

Apple requires every app to provide an accessible privacy-policy link in App Store Connect and inside the app. Its current App Review guidance says the policy should identify what data is collected, how it is collected and used, how long it is retained, how it is deleted, and how a user can withdraw consent or request deletion.

The policy is only one disclosure. App Store Connect also asks for App Privacy answers that appear on the product page. Apple expects those answers to include data collected by third-party partners whose code is integrated into the app. A crash-reporting or advertising library cannot be ignored simply because your own backend never sees its raw events.

Google Play similarly requires a privacy policy in the store listing and within the app. The User Data policy says it must accurately disclose access, collection, use and sharing of user and device data. All published apps must complete the Data safety form, including apps that say they collect no user data.

The practical standard is therefore consistency. The hosted policy, store forms, permission prompts, consent choices and released code should describe the same product.

Start with a data map, not a template

Before drafting, ask the product, backend and mobile teams to fill in one row for every data flow. Include data typed by the user, generated by the service, read from the device and collected by embedded services.

For each row, record the data owner, legal purpose, user-facing explanation, processor or recipient, server region, access roles, retention rule and deletion mechanism. "We use analytics" is not a data map. Name the events, identifiers and provider behavior that matter.

This exercise often removes unnecessary collection. A booking app may not need a date of birth. A courier app may need live location during a shift but not a permanent route history. Removing a field is cheaper and safer than explaining, protecting and deleting it forever.

What the policy should contain

The exact legal wording depends on the market, but a useful mobile privacy policy normally answers a stable set of questions in plain language.

First, identify the company or person responsible for the processing and give a real privacy contact. The company name should agree with the developer identity shown in the store. If a data protection officer or local representative is required, include that route too.

Next, describe categories of data and their sources. Separate account details, device information, user content, transactions, location, contacts, health information and support communications where relevant. Explain whether the user provides the data, the device exposes it, the service creates it or a partner returns it.

For each meaningful purpose, explain why the processing happens. "To improve our services" says very little. "To remember unfinished bookings for seven days" or "to send the courier's position to the customer while an order is active" gives a user something they can evaluate.

The policy should also cover recipients and service providers, international transfers where applicable, security at an appropriate level, retention periods or the rule used to determine them, user rights and how to exercise them, complaint routes, changes to the notice and an effective date.

Do not promise more than the system can deliver. A sentence such as "we delete all data immediately" is inaccurate if financial records must be retained or backups expire on a schedule. State the exception, reason and period clearly.

Policy, store label, permission and consent are different

These four surfaces are related, but one cannot replace the others.

The privacy policy provides the full explanation. Apple's App Privacy section and Google Play's Data safety section provide structured summaries before installation. An operating-system permission lets the user allow or block technical access to resources such as location, camera or microphone. Consent is a legal basis or choice for a specific purpose where consent is appropriate.

Granting camera access does not mean the user agreed to advertising, facial analysis or indefinite storage. Refusing optional analytics should not break a core service that does not depend on analytics. The interface should explain a sensitive request at the moment it becomes relevant, then let the operating system show its permission prompt.

This is why privacy belongs in UX planning. The team may need a short pre-permission explanation, granular settings, a consent history, a download-data path and an account-deletion flow. Those are product states, not paragraphs on a website.

Our authentication and account guide helps define the account lifecycle, while the analytics setup guide shows why event design and privacy review should happen together.

Third-party SDKs are the common blind spot

A mobile binary usually contains code the product owner did not write: analytics, crash reporting, maps, payments, chat, attribution, advertising, support or social login. Those software development kits may access device information, generate identifiers or send data to their own infrastructure.

Apple states that developers are responsible for third-party code and requires privacy manifests for a list of widely used SDKs. Xcode can combine manifests into a privacy report, but the report is an input to review, not a legal policy generator. Read the provider's documentation, inspect configuration and verify actual network behavior in a release build.

Google gives the same ownership warning. Its Data safety instructions require developers to include data collected or shared through libraries and SDKs. Disabling one optional setting may change the correct answer, so keep configuration evidence with the release record.

For each dependency, write down the version, purpose, permissions, data types, destinations, retention information, opt-out behavior and owner inside the team. The Android app security checklist adds checks for permissions, secrets, logs and release configuration.

Account deletion must be a working product flow

If an iOS app supports account creation, Apple requires users to be able to initiate account deletion inside the app. Google Play requires an in-app path and an external web resource where a user can request account and associated-data deletion.

Deleting an account is not the same as hiding a profile or blocking sign-in. The team must decide what happens to active subscriptions, pending orders, user-generated content, messages, invoices, fraud evidence, support tickets and backups. Some records may need to remain for a legitimate legal or security reason, but that retention should be disclosed and access should be limited.

A credible flow confirms the request, handles reauthentication where necessary, explains immediate and delayed effects, cancels future billing where applicable, sends a receipt and creates an auditable support state. Test it with the same care as registration.

Google's account-deletion requirements are a useful implementation reference. Add the deletion acceptance criteria to the mobile app launch checklist rather than discovering the missing flow during review.

Three examples of policies that need different detail

A salon booking app may collect a name, phone number, appointment history and deposit status. Its policy should explain reminders, staff access and how long no-show or payment records remain. It does not need broad language about "biometric information" if the product never handles it.

A delivery app has a more complex route. Customer addresses, courier location, proof-of-delivery photos, payment status and dispatcher access all have different purposes and retention needs. Location disclosure should distinguish live service delivery from background analytics. The estimate must include operational permissions and deletion rules, not only customer screens.

A health or education product may handle data that deserves stronger protection or relates to children. Generic generator text is especially risky here. Define roles, lawful access, export, incident response and vendor contracts before development. Our mobile app security checklist covers the technical side, but legal review should follow the applicable sector and country rules.

Concrete examples improve the policy because they force the team to describe its own service. They also make the notice easier for a user to understand than a long inventory of every legal term that might conceivably apply.

A six-step pre-launch review

1. Freeze the release inventory. Record features, permissions, endpoints, SDK versions, admin tools and external providers in the actual candidate build.
2. Map every data route. Include data collected before sign-in, support tools, notifications, logs, backups and staff exports.
3. Draft from the map. Write the policy and local notices for the markets where the app is offered; ask counsel to review sensitive or regulated cases.
4. Complete store disclosures from the same source. Reconcile Apple App Privacy and Google Data safety answers row by row.
5. Test user control. Deny permissions, withdraw optional consent, request a copy, delete the account and verify what remains.
6. Approve and archive evidence. Assign an owner, effective date and review trigger; store the inventory with release documentation.

The documentation handover guide explains where this evidence should live so it does not disappear when a developer or vendor changes.

Keep the policy accurate after release

A privacy policy can become wrong without anyone editing the page. Adding an attribution SDK, enabling session replay, changing a map provider, collecting a new support attachment or moving infrastructure can change the data flow.

Make privacy review part of change approval. A ticket that adds a provider should answer what data it receives, why it is needed, whether consent or a permission changes, where it operates and how deletion reaches it. A release should not close until the owner confirms whether the policy and store forms need an update.

Review the full inventory on a regular schedule and after every material feature, provider or market change. Keep old policy versions and effective dates. Users should be told about meaningful changes in a way appropriate to their impact, rather than being asked to accept an unread document after every minor edit.

How Appfyl includes privacy in app planning

At Appfyl, the useful starting point is the product flow: who creates an account, what each role can see, which data makes the service work, which providers receive it and how the team resolves a deletion request. That turns privacy from a last-day publication task into visible design, backend, admin-panel and QA work.

During scoping, we separate required data from convenient data and identify sensitive integrations early. The same inventory supports technical architecture, store declarations, test cases and the legal review. It also prevents a low estimate from quietly omitting account deletion, consent settings or staff tools.

You can include permissions, account roles, analytics, third-party services and deletion requirements in the Appfyl estimate brief. For development support, see Appfyl mobile app development.

Want to see how Appfyl turns scope into shipped products? View Appfyl cases.

Questions people ask