App Store Compliance

Every URL and file Apple requires for iOS and macOS App Store submission

Privacy policy URL, support URL, AASA, account deletion, privacy manifest — every page and file App Review verifies for iOS, iPadOS, macOS, tvOS, visionOS, and CarPlay apps.

By · · 12 min read

Apple’s App Review process verifies a specific set of web pages and bundled files before your app is approved. The list is the same whether you’re shipping to the iOS App Store, the iPadOS App Store, the Mac App Store, the tvOS App Store, the visionOS App Store, or shipping a CarPlay-enabled iOS app. Miss one, and the submission bounces back with a guideline number and a wait of one to several days for re-review. None of these requirements are buried — they’re all in Apple’s published guidelines and developer documentation — but they’re scattered across half a dozen pages, and the list has grown over the past three years (account deletion in 2022, privacy manifests in 2024).

This is the complete, current list as of mid-2026, with platform-applicability notes on each item. Every requirement links to the exact Apple source so you can verify before you build, and each section closes with how to satisfy it without writing a website from scratch.

Platform note: Most requirements apply equally across all of Apple’s App Store platforms. The handful that are platform-specific (Apple Pay merchant domain for Safari purchases, AASA file for Universal Links on platforms that support them) are called out inline. CarPlay apps are submitted as iOS apps with the CarPlay Audio / Driving Task entitlement, so every iOS requirement applies to them too.

The TL;DR checklist

Requirement Where it lives Required when
Privacy Policy URL App Store Connect → App Information Always (iOS + macOS)
Support URL App Store Connect → Version Information Always (per Guideline 1.5)
Account Deletion In-app + linked from your support flow If your app supports account creation
App Privacy details (nutrition labels) App Store Connect → App Privacy Always
PrivacyInfo.xcprivacy (privacy manifest) Bundled in your app + any 3rd-party SDKs Always as of May 1, 2024
apple-app-site-association (AASA) Hosted at https://yourdomain/.well-known/ If using Universal Links, App Clips, Web Credentials, or Handoff
apple-developer-domain-association.txt https://yourdomain/.well-known/ If using Sign in with Apple on the web
apple-developer-merchantid-domain-association https://yourdomain/.well-known/ If using Apple Pay on the web
EULA App Store Connect (or Apple’s standard) Always — Apple provides a default
Marketing URL App Store Connect Optional — recommended for discoverability

The rest of this post unpacks each one with the canonical Apple source and the practical implementation notes that aren’t always obvious from the docs.

1. Privacy Policy URL — required for every app

Apple’s App Store Connect Help — App Information reference lists Privacy Policy URL as a required field for every iOS and macOS app (tvOS apps need the policy text inside a separate Apple TV Privacy Policy field instead of a URL). The URL must:

  • Load on a public URL (no login wall, no password protection).
  • Stay live for as long as the app is in the App Store.
  • Disclose every category of data the app collects, how each is used, who it’s shared with, and how users can exercise their rights.
  • Match the privacy practices you declare in App Privacy details (see section 4).

The privacy policy itself is what App Review actually reads — they cross-reference it against your nutrition labels and against the permissions your app requests. A privacy policy that says “we don’t collect data” while your Info.plist requests location access is a fast rejection.

Most common rejections:

  • Page returns 404, 5xx, or expired SSL.
  • Page is inside a CMS that’s blocked from search engine crawling — App Review’s tooling can’t always render JS-only sites reliably.
  • The policy is generic boilerplate that doesn’t mention the app’s actual data practices.

OrbitKit handles this: the privacy policy wizard walks through all 14 Apple data categories and outputs a hosted URL that auto-stays in sync with your declared App Privacy answers. No CMS, no custom domain required to start.

2. Support URL — required by Guideline 1.5

App Store Review Guideline 1.5 — Developer Information states:

“People need to know how to reach you with questions and support issues. Make sure your app and its Support URL include an easy way to contact you; this is particularly important for apps that may be used in the classroom.”

The Support URL is set per-version in App Store Connect (under Version Information, not App Information). What App Review checks when they visit it:

  1. The URL loads with no authentication wall.
  2. Contact information is visible above the fold on iPhone — App Review tests on a phone, not desktop.
  3. There’s a real way to reach a human (email, contact form, or both — not just an FAQ page).
  4. The page works on mobile without horizontal scrolling.

The most common reason a Support URL bounces a submission is that the developer points it at the homepage of their marketing site, which has the contact info three scrolls down past the hero and feature grid.

OrbitKit handles this: every app gets a hosted support page with email, optional phone, optional address, support hours, and an FAQ — all formatted to render correctly on iPhone first.

3. Account Deletion — required for any app with sign-in (since June 30, 2022)

Apple’s Offering account deletion in your app page makes the rule explicit:

“Apps that support account creation must also offer account deletion within the app.”

The requirement is enforced under Guideline 5.1.1(v) — Account Sign-In. Specifics from Apple’s support page:

  • Easy to find — typically in the app’s Settings, alongside Sign Out.
  • Complete deletion — the entire account record and associated personal data, not just a soft-disable. Apple is explicit: “Simply deactivating or disabling accounts is insufficient.”
  • Clear timeline — if deletion isn’t immediate, tell users when it’ll complete.
  • Cover all data — user-generated content (photos, posts, reviews), automatically-created accounts, and accounts tied to subscriptions.
  • Reauthentication is allowed — you can require the user to verify identity before deletion.
  • In-app initiation, web completion is allowed — if the actual deletion happens via a web form, the app must link directly to it (not bury it in a generic support page).

If your app uses Sign in with Apple, you also need to revoke the user’s Apple-issued tokens via the Sign in with Apple REST API as part of the deletion flow. Forgetting this is one of the most common technical-but-quiet rejections.

OrbitKit handles this: the data deletion page generator covers all four methods Apple expects (in-app, email, web form, hybrid), with step-by-step instructions, deletion timeline, and disclosure of any retained data. The hosted URL is what you link to from inside the app.

4. App Privacy details — the nutrition labels questionnaire

Apple’s App Privacy Details on the App Store page documents the disclosure questionnaire you complete in App Store Connect. You must declare:

  • Every data type your app or your third-party SDKs collect (14 categories, ~30 specific data types).
  • How each type is used (App Functionality, Analytics, Product Personalization, App Marketing, Developer’s Advertising or Marketing, Third-Party Advertising, Other).
  • Whether each type is linked to user identity.
  • Whether each type is used for tracking (with the technical definition Apple gives — “linking user or device data collected from your app with user or device data collected from other companies’ apps, websites, or offline properties”).

Your nutrition labels become public on your App Store listing and have to match both your privacy policy URL and your privacy manifest file (next section). Apple actively cross-checks all three.

The optional-disclosure carve-outs Apple allows are narrow: data must (1) not be used for tracking, (2) be collected infrequently and outside primary functionality, (3) be user-provided through your app interface with clear disclosure, and (4) be optional from the user’s perspective. If any one of those four fails, you must disclose.

OrbitKit handles this: the privacy wizard collects answers in the same shape as the App Store Connect questionnaire, so the labels you’ll enter in App Store Connect match what’s in your hosted policy by construction.

5. PrivacyInfo.xcprivacy — privacy manifest, required since May 1, 2024

Apple’s Privacy manifest files documentation describes the file your iOS, iPadOS, tvOS, watchOS, visionOS, or Mac Catalyst app bundle must include. (Standalone Mac apps that don’t share frameworks with the iOS-style platforms are exempt; if you’re using Catalyst or SwiftUI cross-platform code, the manifest applies.) It’s a property list with three sections:

  • NSPrivacyTracking — boolean, whether your app uses data for tracking.
  • NSPrivacyTrackingDomains — list of internet domains your app connects to that engage in tracking. iOS will block these in production builds when ATT permission is denied.
  • NSPrivacyCollectedDataTypes — granular declaration of each data type, whether it’s linked, whether it’s used for tracking, and the purpose codes.
  • NSPrivacyAccessedAPIs — declaration of which Required Reasons APIs you use, with the approved reason codes for each.

Five API categories require declared reasons: file timestamp APIs, system boot time, disk space, active keyboards, and UserDefaults. If you call any of them — directly or via a dependency — without an approved reason in your manifest, App Review rejects with the ITMS-91053 error.

Third-party SDKs ship their own privacy manifests, which Xcode merges into yours at build time. Apple maintains a list of commonly used SDKs that are required to provide manifests — if you depend on any of them and they don’t, the build fails the privacy check.

OrbitKit handles this: the privacy manifest tool generates a PrivacyInfo.xcprivacy file from your wizard answers and returns it as a download you drop into your Xcode project. It also derives the right Required Reasons API codes for the most common SDKs.

6. apple-app-site-association (AASA) — for Universal Links, App Clips, and more

Universal Links work on iOS, iPadOS, macOS, watchOS, and visionOS. If your app uses any of the following, you need an AASA file hosted at https://yourdomain/.well-known/apple-app-site-association:

  • Universal Links — deep links from the web that open your app instead of Safari.
  • App Clips — invocation URLs.
  • Shared Web Credentials — passwords/passkeys synced between Safari and your app.
  • Handoff / Activity Continuation — between iOS, macOS, and the web.

Apple’s Supporting associated domains documentation specifies the file format. Critical requirements that catch developers out:

  • Must be served as application/json — no Content-Type: text/html, no fileextension on the path.
  • Must be served at HTTPS — iOS rejects HTTP and self-signed certs.
  • Must be under 128 KB — Apple’s swcd daemon refuses larger files.
  • No redirects — iOS follows the literal URL; a 301 to a different host fails verification.
  • apple-app-site-association exactly — not applesite.json, not aasa.json, not apple-app-site-association.json.

Apple’s applinks key reference documents the JSON structure for the Universal Links section, including pattern matching, query parameter filtering, and exclusion paths.

OrbitKit handles this: the AASA generator produces a syntactically correct, MIME-type-correct, size-checked file from your App IDs and path patterns, served at /.well-known/apple-app-site-association on your hosted site.

7. Sign in with Apple domain association (web only)

If you use Sign in with Apple on a website (not just inside the app), Apple requires you to host a verification file at https://yourdomain/.well-known/apple-developer-domain-association.txt. The file content is generated when you register your domain in the Apple Developer portal under Services IDs.

If you only use Sign in with Apple inside the iOS app, this file is not required. It’s specifically for the web sign-in flow.

OrbitKit handles this: upload the file Apple gives you and it’s served at the right path with the right MIME type.

8. Apple Pay merchant ID domain association (web only)

Same pattern as Sign in with Apple, for Apple Pay on the web: a verification file hosted at https://yourdomain/.well-known/apple-developer-merchantid-domain-association (no extension), generated by Apple when you register your merchant domain. Required only if you accept Apple Pay payments via Safari on your website. Not required for in-app Apple Pay using PKPaymentAuthorizationViewController.

OrbitKit handles this: same upload-once-and-serve flow as the SiwA file.

9. EULA — Apple provides a default

Every App Store app needs an end-user license agreement. Apple provides a standard EULA that applies by default if you don’t supply your own. For most apps, the default is fine — overriding it with a custom EULA is reserved for cases with non-standard licensing terms (subscriptions with unusual cancellation, app-internal user agreements, etc.).

If you do override, the custom EULA URL must be set in App Store Connect and must satisfy Schedule 1, Exhibit 1 of the Apple Developer Program License Agreement requirements. Most indie apps shouldn’t bother.

10. App Tracking Transparency disclosure (if you track)

If your app or any third-party SDK in it engages in tracking as Apple defines it, you must:

  1. Declare the tracking domains in your PrivacyInfo.xcprivacy (NSPrivacyTrackingDomains).
  2. Request user permission via the App Tracking Transparency framework before initiating any tracking.
  3. Disclose the tracking in your privacy policy and App Privacy details.

This is the framework behind the system “Allow / Ask App Not to Track” prompt. Forgetting to call requestTrackingAuthorization before initializing a tracking SDK is a guideline 5.1.2 violation.

OrbitKit handles this: the privacy wizard’s children-and-tracking section captures whether your app uses tracking and which domains; the output flows into both the policy URL and the privacy manifest file.

What App Review actually does

When you submit an app, Apple’s review tooling automatically:

  1. Visits your Privacy Policy URL and Support URL from a phone-shaped browser.
  2. Cross-references your App Privacy details with the API permissions in your Info.plist and the categories declared in your PrivacyInfo.xcprivacy.
  3. Probes your AASA file (if your app declares associated domains in entitlements) — checks MIME type, size, JSON validity, and path inclusion rules.
  4. Verifies your account deletion flow is reachable inside the app (this one is human-checked) — they will create an account and try to delete it.

A human reviewer also opens the app, taps around, and looks for any disclosed-but-not-implemented privacy practice or any sign-in-required-but-no-deletion flow. Most rejections come from either a broken URL or a mismatch between what your privacy policy says and what the app actually does.

How OrbitKit covers all of it

OrbitKit was built specifically for this list — same checklist whether you’re shipping to the iOS App Store, the Mac App Store, or both. One subscription, one slug like sites.orbitkit.io/your-app, and you get:

  • A hosted privacy policy that matches the App Privacy questionnaire shape.
  • A hosted support page that renders correctly on iPhone with contact info above the fold.
  • A hosted data deletion page with Apple-compliant in-app/email/web-form flows.
  • An AASA file at /.well-known/apple-app-site-association with correct MIME and size validation.
  • A PrivacyInfo.xcprivacy generator that derives Required Reasons codes from your wizard answers.
  • File hosting for the Sign in with Apple and Apple Pay domain association files.
  • A smart app banner meta tag for cross-promotion from web back into the app.

The dashboard preview lets you see exactly what App Review will see before you submit. The whole thing is $5/mo per app, no add-ons, no setup fees — and your first app is free for 30 days (a limited-time launch offer; card required, cancel anytime before it renews). See features for the full breakdown or start your free trial.

Source documentation

Every requirement above traces back to Apple’s published documentation. Bookmark these for reference:

If any of the URLs above breaks — Apple does occasionally restructure their docs — drop us a note at help@orbitkit.io and we’ll update the post.