Apple's Developer Agreement: The Privacy Policy and EULA Rules Your App Must Follow
Every developer accepts the Apple Developer Program License Agreement before shipping a single app. Buried in its pages are hard requirements about privacy policies, user consent, EULAs, and a growing set of rules for age data and on-device AI. Here is what the agreement actually asks of you, in plain language, and how to meet it.
The short version
- 1.A privacy policy is mandatory. It must cover collection, use, disclosure, sharing, retention, and deletion, and its URL goes into App Store Connect.
- 2.You need consent before you collect any user or device data, including data gathered by third-party SDKs.
- 3.If you run ads or analytics, you must honor App Tracking Transparency and disclose it.
- 4.You either accept Apple's default EULA or write your own that meets Schedule 1's minimum terms.
- 5.Newer APIs for age range and on-device AI carry their own data limits that belong in your policy.
Why This Agreement Binds You
The Apple Developer Program License Agreement is not marketing copy. It is the contract you accept, by checking a box or clicking Agree, in order to use Apple's software and services and to distribute your app through the App Store, Custom App Distribution, or TestFlight. Once you accept it, its terms apply to everything you ship, in every region where your app is available.
Most developers skim it once and never look again. That is a mistake, because a good share of what App Review checks, and what can get an app pulled after launch, comes straight from this document. The data and privacy rules in particular are written as obligations you carry, not suggestions. The sections below are the ones that shape the legal documents your app needs.
The Privacy Policy Requirement
Agreement 3.3.3(C)
You must provide a privacy policy in your application, on the App Store, and/or on your website that explains your collection, use, disclosure, sharing, retention, and deletion of user or device data. If that data is ever compromised, you must notify affected users in line with applicable law.
Note the specific verbs. A one line "we respect your privacy" banner does not satisfy this. The policy has to describe:
- What user or device data you collect, including things like IP address, device name, and installed apps
- How you use it and who you disclose or share it with, including third-party SDKs
- How long you keep it, and how a user can have it deleted
The breach notification duty is the part most founders miss, so your policy should say how you would handle one. App Store Connect enforces the requirement at submission by asking for a privacy policy URL, and Apple's App Privacy details, the "nutrition label" on your store listing, must line up with what your policy says. When the label and the policy disagree, that is a common reason for rejection.
Consent Before You Collect
Agreement 3.3.3(B), (D), (F)
You may not collect user or device data without prior user consent, and then only to provide a service directly relevant to the use of the app. You may not broaden the use of data you already collected without asking again.
Two consequences follow that are worth spelling out:
- New purpose, new consent. If you gathered an email for account sign in and later want to use it for marketing, that is a new purpose that needs fresh consent.
- You own your SDKs. If a third-party analytics or advertising SDK collects data, the agreement treats that as your collection, so it has to be disclosed and consented to as well.
Location data gets its own treatment: apps must notify and get consent before location is collected, and continuous "Always" location needs a clear justification shown to the user at the moment you ask. Health research and HealthKit clinical uses require informed consent from participants.
Advertising Identifier and Tracking
Agreement 3.3.3(E)
You may use the Advertising Identifier only for advertising, you must check the user's Tracking Preference through App Tracking Transparency before using it, and you must honor that setting. If a user resets the identifier, you cannot link the old and new values together.
For your documents, the takeaway is simple: if you run ads, analytics, or attribution, your privacy policy needs a clear section on tracking and advertising, and your App Privacy label needs to reflect it. Vague wording here is both a compliance risk and a rejection risk.
Age Data, On-Device AI, and Sensitive Data
Recent versions of the agreement add framework specific rules that matter if your app uses any of these capabilities. Each comes with its own data limits that your privacy policy should reflect.
Declared Age Range API
Lets your app request a user's age range to provide age appropriate content or meet age laws. You may use it only for those purposes, and you may not share or sell the data to data brokers or information resellers. Age assurance is a fast moving area of law, so if you use this API, describe it in your policy.
Foundation Models Framework
Apple's on-device AI framework. By using it you agree to follow the Foundation Models Framework Acceptable Use Requirements and to keep reasonable guardrails in place. If your AI feature captures prompts or user content, that is still data collection and belongs in your consent flow and your policy.
Face Data, Family Controls, and ID Verifier
These carry strict limits. Face Data may not be used for advertising, profiling, or authentication, and may not leave the device without clear consent. Data from the Family Controls Framework may be used only to provide those controls and never shared with a data broker. ID Verifier data must be stored securely and used only to verify age or identity.
One more limit worth flagging: unless Apple permits it in writing, you may not use iCloud, CloudKit, or related services to handle protected health information, or use them in a way that would make Apple your business associate under HIPAA. If you build in health, read section 3.3.3(D) closely.
The EULA Requirement
Schedule 1, Minimum Terms
Separate from your privacy policy, every app is licensed to users under an end user license agreement. Apple provides a standard default EULA that applies automatically, and for many simple apps that is enough. If you want your own terms, Schedule 1 lists the minimum terms it must contain. Here is how the two documents compare:
| Privacy Policy | EULA | |
|---|---|---|
| What it governs | How you handle user and device data | How people may use the app itself |
| Required by Apple? | Yes, always (3.3.3.C) | Yes, but Apple's default counts |
| Where it lives | In app, on the store, and/or your site | Presented for user acceptance |
| Write your own? | Always, tailored to your data | Optional, must meet Schedule 1 terms |
If you write your own EULA, Schedule 1 requires, among other terms:
- An acknowledgement that the license is between you and the user, not Apple, and that you alone are responsible for the app and its content
- A license scope limited to the user's own Apple-branded devices, with Family Sharing allowed
- That you, not Apple, provide maintenance, support, and warranties
- That you handle any product, IP, or consumer protection claims
- Your name, address, and contact details for user questions and complaints
- That Apple is a third-party beneficiary who can enforce the EULA against the user
If your product is a SaaS app or a game with its own rules, a proper EULA is usually worth writing rather than relying on the default. It is also the document users actually agree to, so getting the acceptance flow right, ideally a clickwrap where the user actively agrees, is what makes it enforceable.
A Short Compliance Checklist
None of this requires a lawyer on retainer, but it does require documents that are accurate to what your app does. A copied template that describes data you do not collect, or misses data you do, is worse than useless at review time.
Generate an App Store ready privacy policy and EULA
PolicyForge drafts both, shaped around what your app actually does and aligned with Apple's requirements plus GDPR and CCPA. Answer a few questions, host the result at a public URL, and paste that URL into App Store Connect.
Frequently Asked Questions
Does Apple actually require my app to have a privacy policy?
Yes. Section 3.3.3(C) of the Apple Developer Program License Agreement says you must provide a privacy policy in your application, on the App Store, and/or on your website that explains your collection, use, disclosure, sharing, retention, and deletion of user or device data. App Store Connect also blocks submission until you supply a privacy policy URL, so this is enforced at review time, not just on paper.
Do I need a privacy policy even if my app collects almost no data?
In practice, yes. Almost every app touches some user or device data, whether that is an email address at sign up, an IP address, crash logs, or an analytics SDK. Apple requires the policy regardless of volume, and it must be accurate about what you collect. A short, honest policy that says exactly what little you gather is fine; having none is not.
What is the difference between a privacy policy and a EULA for the App Store?
A privacy policy explains how you handle user data. A EULA, or end user license agreement, is the contract that governs how people may use your app itself. Apple provides a standard default EULA, but if you supply your own it must include the minimum terms in Schedule 1 of the agreement, including your name and contact details and an acknowledgement that the license is between you and the user, not Apple. Many apps need both documents.
What is the Declared Age Range API and why does it matter for privacy?
It is a newer Apple API that lets your app request a user's age range so you can offer age appropriate content or meet age related laws. The agreement restricts it tightly: you may use it only for those purposes, and you may not share or sell the data to data brokers or information resellers. If your app relies on it, your privacy policy should describe that you receive age range information and how you use it.
Does the agreement say anything about AI features in my app?
Yes. If you use Apple's Foundation Models Framework, which gives apps access to on-device models, you agree to follow Apple's Foundation Models Framework Acceptable Use Requirements and to keep reasonable guardrails in place. If your AI feature collects prompts or user content, that collection still falls under the same consent and privacy policy rules as any other data, so disclose it.
Can PolicyForge generate documents that meet these requirements?
Yes. PolicyForge drafts privacy policies and EULAs shaped around what your app actually does, covering the collection, use, disclosure, retention, and deletion language Apple asks for, plus GDPR and CCPA requirements. You answer a few questions, host the result at a public URL, and paste that URL into App Store Connect. Free accounts can start without a credit card.
This article is general information, not legal advice, and it summarizes the Apple Developer Program License Agreement as we read it. Apple updates the agreement from time to time, so check the current version in your Apple Developer account, and consult a qualified lawyer for your specific situation.