Compliance

The App Store Support URL: Requirements, Examples, and the Fastest Way to Build One

What Apple actually requires from your App Store support URL, why marketing pages get rejected, and an honest comparison of the fastest tools (Notion, Carrd, Google Sites, Linktree) vs. purpose-built options.

10 min read

The App Store Support URL: Requirements, Examples, and the Fastest Way to Build One

You have your app ready, your screenshots uploaded, your privacy policy URL pasted in. Then App Store Connect asks for a support URL and you realize you do not have one. You paste your homepage, submit the build, and a day later the review rejects the app because "the Support URL does not provide an easy way to contact you." Welcome to a rejection most first-time submitters hit exactly once.

This guide explains what Apple actually wants from a support URL, why a marketing homepage almost always fails review, how solo developers build one in under an hour using tools they already have, and when to reach for something purpose-built instead.

TL;DR

  • A working, publicly accessible support URL is required for every App Store submission. Apple's App Review Guidelines call it out directly in Section 1.5.
  • It cannot be your marketing homepage, a social media profile, or a page that requires login.
  • At a minimum, the page must provide a way for a user to contact you and must be specific to the app being submitted.
  • Solo developers can ship a compliant page in under an hour with Notion, Carrd, Google Sites, or Linktree — each with trade-offs.
  • A purpose-built solution gives you a proper support center (FAQ, ticket system, per-app branding) without stitching multiple tools together.

Table of Contents

What Apple Actually Says

The App Review Guidelines, Section 1.5 (Developer Information), state the requirement clearly:

"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. Failure to include accurate and up-to-date contact information not only frustrates customers, but may violate the law in some countries or regions."

There are three things to notice in that paragraph. First, the support URL is treated as a required part of the submission — "make sure your app and its Support URL include." Second, Apple specifies "an easy way to contact you" — not a way to contact your entire company, not a way to contact your lawyer, not a way to subscribe to your newsletter. Third, Apple flags legal exposure — in some jurisdictions, failing to provide clear contact information for a consumer-facing product is a regulatory issue independent of App Store policy.

The "Before You Submit" checklist in the same document tells you explicitly: "Update your contact information in case App Review needs to reach you." Reviewers will click the URL. A broken or irrelevant page is one of the most common soft rejections.

Why Marketing Pages Get Rejected

The first instinct for most developers is to paste their homepage URL into the support field. It is public, it is reachable, it has a contact form somewhere — surely that counts. It usually does not, and the reasons are consistent across rejection reports.

The page is not about the app. A marketing site for a company with five apps has no way for a user to tell which app the help relates to. Apple expects the support page to be specific to the app being submitted.

The contact method is hidden. A homepage that has "Contact" buried in the footer, behind a hamburger menu, or behind a "Talk to sales" funnel does not meet the "easy way to contact you" standard.

Social media is not enough. An X, Instagram, or Facebook profile as a support URL is one of the fastest rejections. Apple wants a working web page, not a social account where DMs can be turned off or rate-limited.

Login walls. If clicking the URL asks the user to create an account or log in before seeing help, it fails. Support must be reachable cold.

Dead pages or placeholder content. Pages with "Coming soon," "Lorem ipsum," or broken links fail. Reviewers check.

Generic FAQ irrelevant to the app. A legal-boilerplate FAQ that does not mention the app's actual features is treated the same as no FAQ at all.

What the Support Page Must Contain

Synthesizing Apple's wording with rejection patterns and developer reports, a compliant App Store support page should include:

  • The app name and icon, or at least a clear heading that names the app the page is for.
  • At least one working contact method — a support email address, a contact form, or a ticket system. A generic info@ address is weaker than a dedicated support@, but either is accepted.
  • A short FAQ section that addresses the questions real users actually ask about the app. Three to five entries is enough for a new app.
  • Troubleshooting guidance for common issues — crashes, login problems, purchase restoration, subscription management.
  • Version or update information — the current version of the app and what the last update changed.
  • Legal links — privacy policy and terms of service should be reachable from the support page.
  • Mobile-responsive layout. Most users who tap the support link are already on a phone.

Nothing here is hard to produce. The challenge is that a good support page is made of six small things, and every DIY tool only gives you four of them.

Four DIY Options for a Support Page

Most solo developers eventually try one of these four.

Notion

A public Notion page with toggle blocks for each FAQ entry, a support email, and a contact form embed.

Pros.

  • Set up in under half an hour.
  • Easy to update — the page is just a Notion doc you already know how to edit.
  • Toggle blocks make a long FAQ scannable.
  • Free on the personal plan.

Cons.

  • The URL looks like notion.site/... which does not inspire confidence in reviewers.
  • No native contact form — you have to embed a third-party form or rely on an email link.
  • Notion's default page chrome includes "Made in Notion" branding on the free tier.
  • Load time is slower than a static page, which can be an issue on mobile networks.

Best for. Fast-moving solo developers who already live in Notion and do not mind the hosted URL.

Carrd

A single-page site builder that gives you a clean, mobile-responsive page on a free subdomain, with a custom domain available for a small annual fee.

Pros.

  • Genuinely beautiful out of the box with minimal design effort.
  • Native contact form on the paid tier.
  • Custom domain support for roughly $19/year.
  • Pages load fast and are mobile-first by design.

Cons.

  • The free tier does not include form handling, so you need to either pay or embed a third-party form.
  • Single page — if you want a separate FAQ page, you are stretching Carrd's model.
  • No per-app structure; if you have multiple apps you build multiple Carrd sites.

Best for. Developers who want the prettiest possible result for a tiny budget and only one app.

Google Sites

A free drag-and-drop site builder that integrates with Google's broader toolset.

Pros.

  • Completely free with no paid tier needed for the basics.
  • Familiar interface if you use other Google tools.
  • Works well for embedding Google Forms as a contact form.
  • No ads, no branding to remove.

Cons.

  • Default design is the plainest of the four options.
  • Google Sites URLs are long and awkward — sites.google.com/view/yourapp — unless you attach a custom domain.
  • Limited layout control compared to Carrd.
  • Some reviewers have reported Google Sites pages loading slowly from outside certain regions.

Best for. Developers who want the absolute cheapest, most reliable option and do not care about visual polish.

Linktree

A link-aggregator page that lists your support email, FAQ, privacy policy, and terms as a bulleted stack of links.

Pros.

  • The fastest setup of any option — 10 to 15 minutes.
  • Mobile-first by default.
  • Free tier is more than enough for a simple support page.
  • Familiar format that users recognize.

Cons.

  • It is a list of links, not a support page. Reviewers sometimes reject it because it does not actually provide help, only pointers to help elsewhere.
  • The Linktree visual brand is prominent and may make the page feel like a shortcut rather than a real support center.
  • Apple has historically been inconsistent about accepting Linktree — some apps pass, some get asked for a real page.
  • No FAQ structure; you are just linking out.

Best for. Developers shipping a pre-launch or side project who accept the risk of a follow-up review round.

The Purpose-Built Option

Every option above gives you a URL in under an hour. None of them give you a structured support center: a searchable FAQ, a ticket system that routes replies to you, per-app branding that matches the rest of your compliance assets, and multi-language coverage for users outside your home market.

AppLander was built to solve this exact set of problems for mobile app developers. Every app you create in AppLander gets a full support center at yourapp.applander.io/support — or at a custom domain — that includes:

  • A searchable FAQ with categories, organized per app.
  • A ticket submission form that routes messages to your AppLander dashboard.
  • A contact email alternative for users who prefer it.
  • Version and changelog information pulled in from the same dashboard.
  • A privacy policy and terms of service that live next to the support page and share the same visual identity.
  • Multi-language publishing — the same FAQ can be translated and served in multiple locales.

Because AppLander also hosts your privacy policy, terms, account deletion page, and landing page, the support URL you submit to Apple is part of a coherent per-app public presence rather than a one-off page built in a different tool with a different visual style.

Honest limitations. If you already have a polished marketing site with a support section, AppLander is redundant and you should use what you have. If you need nothing more than "a URL that lists an email address," Linktree will get you there faster. Where AppLander wins is the common middle case: a developer who needs a real support center and does not want to build or maintain one from scratch.

Decision Table

Tool Setup time Cost FAQ support Ticket system Custom domain Per-app structure Best for
Notion ~30 min Free Yes (toggle blocks) No Paid No Existing Notion users
Carrd ~30 min Free tier, paid for forms Limited (single page) No Paid (~$19/year) No Best-looking result on a budget
Google Sites ~20 min Free Limited Via Google Forms Paid No Absolute cheapest
Linktree ~15 min Free No No Paid No Risk-tolerant side projects
AppLander ~15 min Free to start Yes (searchable, categorized) Yes (native dashboard) Yes Yes Developers shipping a real support center

How to Enter the URL in App Store Connect

Once the page exists:

  1. Sign in to App Store Connect.
  2. Open your app.
  3. Under App Information in the sidebar, find the General Information section.
  4. Scroll to the Support URL field (it appears alongside Marketing URL and Privacy Policy URL).
  5. Paste the full URL, including https://.
  6. Save the changes.
  7. Before submitting the build, open the URL yourself on a phone in an incognito browser. If it does not load, reviewers will not accept it.

The Marketing URL field is optional — Apple shows it on the product page if you provide one, but a missing marketing URL does not block submission. Privacy Policy URL, on the other hand, is also required; see our privacy policy generators guide if you need one.

Frequently Asked Questions

Is the support URL really required, or can I skip it?

It is required. Section 1.5 of Apple's App Review Guidelines states that your app and its support URL must include an easy way to contact you. Missing or broken contact information is one of the most common soft rejections on first submission.

Can I use a social media profile as my support URL?

No. Apple rejects social profiles as standalone support URLs because DMs can be disabled, rate-limited, or inaccessible to users who are not signed in to that platform. A real web page is required.

Can I use the same support URL for multiple apps?

You can, but it is risky. Apple expects the page to be specific to the app being submitted. If you have multiple apps, a shared support page must clearly show which app is which and provide app-specific information. Per-app pages pass review more reliably.

Does the support URL need to match my developer name?

No. The domain does not have to match your developer account name. What matters is that the page clearly identifies the app and provides real support content.

What if my app has no real users yet and there are no real FAQs to write?

Write honest pre-launch FAQ content. Answer questions like "How do I reset my password?", "How do I cancel my subscription?", "Which devices are supported?", "How do I report a bug?" These are universal and valid even for a brand-new app.

Is the marketing URL required too?

No, the marketing URL is optional. If you provide one, Apple shows it on the product page; if not, the field is simply empty. The privacy policy URL and the support URL are the two mandatory URLs.

How does this relate to the privacy policy and account deletion URL requirements?

They are three separate required URLs. The support URL is for reaching you with help questions, the privacy policy URL describes your data practices, and (for Play Store apps that have accounts) the account deletion URL lets users delete their accounts. See our Google Play account deletion URL guide for the deletion side.

Conclusion

An App Store support URL is one of the smallest possible compliance items and one of the most common sources of first-submission rejection. The fix is not glamorous: a page that names the app, lists an email address, answers a handful of real questions, and loads fast on a phone. Any of the DIY tools above can produce that page in under an hour, and any of them will pass review if you follow the checklist in this guide.

If the support URL is the only compliance asset you need, pick whichever of the DIY tools feels least like homework. If you also need a privacy policy, terms, FAQ, account deletion page, and a landing page — which most App Store submissions require — try AppLander. It gives you all of them under one dashboard, at one URL per app, with the same visual identity across every compliance asset.

Sources

Ship your app faster with AppLander

The all-in-one compliance and landing-page platform for mobile app developers.

Start Free