By platform

Privacy Policy Generator for iOS Apps

Written for App Store review: privacy nutrition labels, ATT, required-reason APIs and the privacy manifest.

Generate your privacy policy Read the privacy policy guide

An iOS privacy policy is reviewed by a human at Apple against the App Privacy details you declared, so it has to be precise in exactly the places a generic web policy is vague: which SDKs collect what, which data is linked to the user, and which is used for tracking.

Apple does not merely require a privacy policy URL - it requires the policy to be consistent with the App Privacy details you declare, and review rejects submissions where they diverge. The nutrition label, the manifest and the policy are three views of the same facts, and reviewers compare them.

App Tracking Transparency governs cross-app and cross-site tracking. Accessing the advertising identifier or linking user data with third-party data for advertising requires the ATT prompt, and the policy has to describe the same behaviour the prompt asks about.

Privacy manifests added another layer. SDKs must declare their data collection and their use of required-reason APIs, and apps must include the manifests of the third-party SDKs they bundle. The SDK list is therefore also a recipients list.

What a privacy policy for an iOS app has to cover

Data types matching your App Privacy declarations - used to track, linked to the user, not linked
Every third-party SDK as a named recipient, with what it collects
ATT and the advertising identifier, described consistently with the prompt
Permissions requested and the specific purpose for each
Account deletion: how it is initiated in-app and what is retained afterwards

Keep the policy at a permanent URL and link it both in App Store Connect and from a settings screen inside the app. Reviewers check that the URL resolves publicly, and a policy behind a login is a rejection.

How an iOS app actually moves personal data

Device and advertising identifiers

IDFA access requires ATT authorisation. IDFV, and vendor SDK identifiers, are separate and still personal data in most regimes.

Analytics and crash reporting SDKs

Firebase, Crashlytics, Amplitude and similar collect device, session and event data and transmit it to their own infrastructure.

Attribution and advertising SDKs

AppsFlyer, Adjust, Meta and Google SDKs perform exactly the cross-party linking ATT governs.

In-app purchases and subscriptions

Apple handles payment, but you receive transaction identifiers and subscription status, which are linked to the user.

Permissions-gated data

Location, contacts, photos, microphone, health and motion each require a purpose string that must match the policy.

Push tokens

Device tokens tied to installs, retained for as long as notifications are enabled, and a recipient relationship with your push provider.

Third parties the draft will ask you about

Apple · Firebase and Crashlytics · Amplitude or Mixpanel · AppsFlyer or Adjust · Sentry · RevenueCat · OneSignal · AWS or Google Cloud

The rules that apply

App Store Review Guideline 5.1

A publicly accessible privacy policy URL is mandatory, covering data collected, use, retention and third-party sharing, plus a way to revoke consent and request deletion.

App Privacy details (nutrition labels)

Declared per data type across data used to track, data linked to the user and data not linked. Must match the policy.

App Tracking Transparency

The ATT prompt is required before tracking, and the policy has to describe tracking consistently with it.

Account deletion requirement

Apps offering account creation must offer in-app account deletion, not merely a support email.

Privacy manifests and required-reason APIs

Apps and SDKs declare collected data and the approved reasons for using certain APIs, which surfaces third-party collection you may not have documented.

What the generated privacy policy contains

Identity and contact details of the controller
Your legal entity, trading name, registered address and a working contact route - plus a representative or DPO where one is required.
Categories of personal data and their sources
What you collect directly, what you observe automatically, and what you receive from third parties such as payment providers or ad platforms.
Purposes and lawful basis, purpose by purpose
A table that pairs each processing purpose with its lawful basis rather than listing all six bases and hoping one fits.
Recipients and sub-processors
The categories of recipient, and for the ones that matter to users - payment, hosting, analytics, support - the named provider.
International transfers and their safeguards
Where data leaves its home jurisdiction, and the mechanism relied on: adequacy, standard contractual clauses, the UK addendum or IDTA.
Retention periods per data category
Concrete periods or the criteria used to set them, which is what regulators ask for first when a complaint lands.
Rights and how to exercise them
Access, rectification, erasure, portability, objection and restriction, with the actual route to make a request and the deadline you work to.
Complaints and supervisory authority
The regulator a user can escalate to, named, with a link - not a generic "your local authority".

Getting through App Store review

Inventory every SDK and what it collects
Including transitive dependencies. Privacy manifests make this list explicit.
Write the policy, then fill in the nutrition labels from it
Not the other way round - the policy is the document with room to be precise.
Host the policy at a stable public URL
Same URL in App Store Connect and inside the app’s settings screen.
Implement in-app account deletion
Reachable in a few taps, with a clear statement of what is deleted and what is retained by law.
Align ATT prompt copy with the policy
Both should describe the same tracking in the same terms.
Re-check on every SDK update
A new SDK version can change what is collected and what the manifest declares.

Where this usually goes wrong

Nutrition labels that do not match the policy

The most common privacy-related rejection. Reviewers read both.

Tracking without an ATT prompt

Or presenting the prompt after the SDK has already started collecting.

No in-app account deletion

An app that lets users register must let them delete in-app. A support email is not sufficient.

Undeclared third-party SDK collection

SDKs collect on their own account, and the privacy manifest requirement has made those flows visible to Apple.

Vague permission purpose strings

"To improve your experience" is rejected. The string has to explain the specific use.

A policy URL that 404s or sits behind a login

It must be publicly reachable, and reviewers check it.

Frequently asked questions

Does my iOS app need a privacy policy?

Yes. App Store Review Guideline 5.1.1 requires a publicly accessible privacy policy URL for every app, with no exception for free apps or apps that collect little data.

What happens if my nutrition labels do not match my policy?

Rejection is common, and inconsistency between declared collection and actual behaviour can also be a deceptive-practice issue with regulators independently of Apple.

Do I need an ATT prompt?

If you access the advertising identifier or link user data with third-party data for advertising or measurement, yes. Analytics used only for your own product typically does not require it, but SDK defaults often do more than expected.

Is in-app account deletion really mandatory?

Yes for apps that support account creation. It must be initiated inside the app rather than only through a website or support request.

Is a privacy policy legally required?

If you process personal data, in almost every market yes. GDPR and UK GDPR require the disclosure at the point of collection, CCPA/CPRA requires a notice at collection plus an annually reviewed policy, and app stores and payment processors require a public policy URL before they will list or onboard you.

Can I copy another company’s privacy policy?

It is both a copyright problem and a compliance problem. A copied policy describes someone else’s data flows, processors and retention periods, so it is inaccurate the moment you publish it - and an inaccurate transparency notice is itself a breach of GDPR Article 13.

How often does a privacy policy need updating?

Whenever your processing changes - a new analytics tool, a new payment provider, a new market - and as a backstop, review it annually. CPRA makes the twelve-month review explicit.

Does PolicifyAI give legal advice?

No. PolicifyAI is a technology provider, not a law firm. The output is a structured, jurisdiction-aware draft that a qualified adviser should review before you rely on it.