App Store Legal Pages: How to Set Up Your iOS App Website, Support URL, and Privacy Policy

When developers search for app store legal pages, they’re usually trying to satisfy App Store Connect requirements for: a Support URL, a Privacy Policy URL, and often an app website or marketing page. Depending on your app, you may also need Terms of Use, EULA links, or additional disclosures (especially if you collect data, use subscriptions, or target kids).

Apple’s requirements vary by app features and what you declare in App Privacy and subscriptions. The safest approach is to publish at least these public URLs: App landing page (optional but recommended), Support page, Privacy Policy page. Then add Terms of Use if you have subscriptions, accounts, or any contractual rules you expect users to follow.

Minimum recommended pages: 1) App landing page: basic product info and links. 2) Support page: contact methods and FAQs. 3) Privacy Policy page: what data you collect and why, and how users can reach you about privacy.

Often needed: 4) Terms of Use: especially if you offer subscriptions, user-generated content, or account-based features. 5) Account deletion instructions: required if your app supports account creation (Apple requires an in-app option to delete accounts, and it helps to also document it publicly).

Checklist before you submit: All links are publicly accessible (no login). Pages load on mobile. URLs are stable (not temporary preview links). The app name on the pages matches your App Store listing. Your support email uses a domain you control if possible. Privacy Policy content matches what you selected in App Store Connect (data collection, tracking, and purposes).

A landing page doesn’t have to be a full marketing site. For App Store review, the important part is that it’s real, consistent with your app, and not misleading. A clean one-page site is often enough.

Include: app name and a one-sentence value statement, key features (2–6 bullets), screenshots (optional but helpful), links to the App Store listing (once live), Support, Privacy Policy, and Terms (if you have them). Add a contact email. If you have subscriptions, mention pricing is handled via in-app purchase and link to Terms.

Example landing page copy you can adapt:

AppName helps you track habits with quick daily check-ins and simple insights. Features: Create unlimited habits; Reminders and widgets; Streaks and progress charts; iCloud sync across devices. Support: https://yourdomain.com/support Privacy Policy: https://yourdomain.com/privacy Terms: https://yourdomain.com/terms Contact: support@yourdomain.com

Your Support URL should not be a generic home page unless the support info is clearly visible. Apple and users expect a page that provides a way to get help quickly.

Include: contact email, optionally a contact form, a short FAQ, and links to privacy and terms pages. If your app uses login or subscriptions, add troubleshooting steps for common issues (restore purchases, sign-in problems). If your app uses device features (camera, health, location), include permission troubleshooting.

Support page example structure:

Header: Get support for AppName. Section 1: Contact (Email: support@yourdomain.com, typical response time). Section 2: FAQs (How to restore purchases; How to turn on notifications; How to export data). Section 3: Report a bug (what info to include: iOS version, device, steps to reproduce). Section 4: Links (Privacy Policy, Terms of Use).

A privacy policy should be specific to your app. The most common reason developers get stuck is mismatch: the policy says “we do not collect data” while App Store Connect declares analytics, identifiers, or crash data collection. Align these three places: the app’s actual behavior, App Privacy selections in App Store Connect, and your public policy page.

At minimum include: what data you collect (or don’t collect), how you use it, whether it’s shared with third parties, retention, security, user choices, and how to contact you. If you use third-party SDKs (analytics, crash reporting, ads), name them or at least describe the categories clearly. If you use Apple frameworks like iCloud, describe that data is stored in the user’s iCloud account where applicable.

If you claim “no data collected,” confirm you truly collect none, including crash logs that identify a device, analytics events tied to an identifier, or email addresses for support. If you do collect support emails, state that you collect the email and message contents to respond to requests.

Privacy policy example (short-form you can expand): 1) Data we collect: Account info (if any), Usage data (optional), Diagnostics (optional), Support communications. 2) How we use data: Provide app functionality, improve stability, respond to support. 3) Sharing: Service providers (e.g., crash reporting) only as needed. 4) Retention: Stored as long as needed for support and legal compliance. 5) Your choices: Opt out of analytics (if offered), delete your account (if applicable). 6) Contact: privacy@yourdomain.com

A Terms of Use page is not always required for free apps with no accounts and no subscriptions, but it is strongly recommended if you have subscriptions, user accounts, community features, or any content that could create disputes.

If you offer subscriptions, include: subscription name(s), billing period, auto-renewal terms, how to cancel (through Apple ID subscriptions), restore purchases, and a link to Apple’s EULA if you’re using it. If you have user-generated content, include acceptable use rules and moderation policy. If you rely on third-party services, include disclaimers and limitation of liability appropriate for your jurisdiction.

Simple Terms example bullets: Eligibility; License to use the app; Subscription terms (if any); Prohibited conduct; Intellectual property; Disclaimers; Limitation of liability; Termination; Changes; Contact.