App Store Compliance

Shipping your first app after WWDC: the web requirements Xcode never mentions

Every June, WWDC produces a wave of finished first apps that stall at submission — not on code, but on the web URLs Apple requires. Here's the whole non-code checklist.

By · · 8 min read

Every WWDC ends the same way: a few weeks of new APIs, sample code, and momentum, and a wave of developers who finish their first app. Then they open App Store Connect to submit — and discover the part nobody’s tutorial covered. Xcode compiled, signed, and archived the binary. It did not produce the web URLs Apple requires before that binary can ship.

This is the durable, every-year version of that checklist: the things App Store submission needs that have nothing to do with Swift, why they exist, and the order to do them in. It’s evergreen on purpose — the APIs change each June; this list doesn’t.

For the exhaustive field-by-field reference, see every URL and file Apple requires for an iOS App Store submission. This post is the map; that one is the territory.

Why your first submission stalls on the web, not the code

Xcode owns the binary. App Store Connect owns everything around it — and several of those fields are URLs that must point at live, public pages you host. Apple’s App Store Review Guidelines are platform-wide and don’t care that this is your first app. A missing or broken URL is a rejection (or a blocked submission) exactly like a crash is.

First-time submitters get surprised here because the web requirements are invisible from inside Xcode. Nothing in the build process tells you that you also need a hosted privacy policy. You find out at the submission screen, after the hard part felt done.

The non-code checklist (in dependency order)

1. A hosted Privacy Policy URL — required for every app, no exceptions

App Store Connect’s App Information screen requires a Privacy Policy URL for every iOS and macOS app. There is no “my app collects nothing” exemption — a no-data app still needs a policy that states it collects nothing. The field is mandatory and the URL must be live and stay live for the life of the app.

This is the single most common thing that stalls a first submission. Details, including the no-data case, are in does a no-data app still need a privacy policy? and the practical generator options in iOS privacy policy generator.

2. Your App Privacy answers must match that policy

Separately from the URL, you complete Apple’s App Privacy questionnaire — the “nutrition label.” The trap for first apps: an analytics or crash-reporting SDK collects data even though your code doesn’t, so “Data Not Collected” plus a bundled SDK is a contradiction App Review catches. That mismatch produces the data-collection rejection email. The policy, the questionnaire, and the privacy manifest must all tell the same story.

3. A Support URL — a real page, not a mailto:

Guideline 1.5 requires a support URL with a way to reach you. App Review opens it on a phone; an empty placeholder or a bare email link is a common first-timer rejection. What actually passes is covered in creating a compliant App Store support URL.

4. An account-deletion path — only if your app has accounts

If users can create an account in your app, Guideline 5.1.1(v) requires an in-app account-deletion flow and the supporting web page. If your first app has no accounts, this doesn’t apply — don’t add it. The decision tree is in the account deletion flow guide.

5. A privacy manifest in the bundle

PrivacyInfo.xcprivacy ships inside the app, declaring Required Reason API usage and what you and your SDKs collect. It’s the one item on this list Xcode touches — and it must agree with items 1 and 2. See the Required Reason API reference and our complete reference.

6. AASA — only if you use Universal Links / App Clips / Passkeys

If your app deep-links from the web, supports an App Clip, or uses Passkeys, you need an apple-app-site-association file served at the exact path with the right content type and no redirects. Most first apps don’t need this on day one; if yours does, Universal Links / AASA without nginx is the no-web-server path.

The order that avoids rework

First-timers usually discover these one rejection at a time. Do them in this order instead and you submit once:

  1. Decide your real data practices (including every SDK you added).
  2. Write the privacy policy from that truth and host it at a stable URL.
  3. Answer the App Privacy questionnaire to match the policy.
  4. Generate the privacy manifest from the same answers.
  5. Stand up the support page (and deletion page only if you have accounts).
  6. Add AASA only if you actually use Universal Links/App Clips/Passkeys.
  7. Paste the URLs into App Store Connect and submit.

The unifying principle: items 1–4 are the same set of facts expressed four times. Write them once, derive the rest, and the cross-checks App Review runs pass by construction. Apple’s own submission overview and distribution docs cover the binary side; this list is the web side that sits beside it.

Two paths from here

How OrbitKit handles it

OrbitKit exists for exactly this gap: it turns one wizard pass into the hosted privacy policy, support page, deletion page (if you need it), AASA file, and a paired PrivacyInfo.xcprivacy — all derived from the same answers, so the surfaces App Review cross-checks agree by construction. Your URLs live on your own domain with automatic SSL and stay live for the life of the app. Your first app is free for 30 days (limited-time launch offer; card required, cancel anytime before it renews), then $5/mo per app. Start your free trial or see features.