Quick answer: Yes, effectively — but not a website, just a page. Apple requires a support URL for every app in App Store Connect, plus a privacy policy URL, and Google Play requires a privacy policy URL and contact details. All of them are listing fields that want live, publicly reachable web addresses. One single-page site on your own domain satisfies every one of them, and takes an afternoon.
| Store field | Required by | Can a one-page site cover it? |
|---|---|---|
| Support URL | Apple, every app | Yes — a support section with a contact email |
| Privacy policy URL | Apple and Google, every app | Yes — a /privacy page |
| Marketing URL | Apple, optional | Yes — the page itself |
| Contact details | Google Play listing | Yes |
If you have built an app and never built a website, this is the requirement that arrives out of nowhere. You are ready to submit. App Store Connect asks for a Support URL. It is not optional, and there is no "I don't have one" checkbox.
What the stores actually demand
Apple, for every app:
- Support URL — shown on your listing as App Support. It must lead somewhere a user can get help.
- Privacy policy URL — a public page describing what your app collects.
- Marketing URL — optional, and usually the same page.
Google Play, for every app:
- Privacy policy URL on the store listing.
- Contact details — an email address, with a website and phone optional.
Every one of these is a field that wants a URL. None of them can be satisfied from inside the app.
The good news: this is one page, not a website
People hear "you need a website" and picture a multi-page project with a blog and a design system. What review actually needs is:
- your app's name and a one-line description,
- a screenshot or two,
- a contact email that you monitor,
- a short FAQ or "having trouble?" section,
- a link to a privacy policy page.
That is a single page plus a /privacy page. It does not need a CMS, a framework, or a deploy pipeline. The app privacy policy generator writes both the policy and the support text for you, so what is left is somewhere to put them.
Why it has to be your own domain
You could technically point these fields anywhere. Three reasons not to:
- Reviewers reject fragile links. Document-sharing URLs, pages behind a login, and links that trigger a download are recurring rejection causes. A plain page on a plain domain never has this problem.
- You need the domain anyway. Your application ID —
com.yourdomain.yourapp— is reverse-domain notation, and it is permanent once published. Deriving it from a domain you do not own is the one mistake in a launch you can never take back. - The support URL is a public trust signal. It sits on your listing.
acmenotes.comand a link to a file-sharing service say different things to someone deciding whether to install.
Check the domain for your app name →
Check the domain in the same pass as the app name itself — a name that is free on the App Store but has no reasonable domain available is worth knowing about before you commit. The App Store Name Checker does both at once, along with the package ID and your social handles.
Getting the page live today
If you write code, static hosting takes an hour. If you do not, use a one-page builder: Carrd exists for precisely this — a single responsive page on your own domain, with the sections you need, for a few dollars a year. It clears the support URL, the privacy policy URL and the marketing URL in one go, which is three blocking requirements removed in an afternoon.
The rest of the gate
Domain and page are one of eight things standing between your build and a live listing. The Ship an App path walks the whole sequence — name, trademark, the permanent package ID, the icon, the privacy policy, the budget, and the submission rules that catch most first-timers.
