App Store Compliance

Creating a compliant App Store support URL for your iOS app

What App Review actually checks when it visits your Support URL — and why the most common rejections come down to four fixable issues. Plus a structure that passes review on the first try.

· 7 min read

The Support URL field in App Store Connect is one of those checkboxes that looks trivial — paste a link, ship the app — and ends up bouncing more first-time submissions than the privacy policy field. App Review actually visits the URL, on a phone, and they have specific things they’re looking for. If those things aren’t visible, your submission goes back into the queue.

This is what App Review checks, what trips up indie developers most often, and a structure for a support page that passes review without negotiation.

What Apple actually requires

Apple’s App Information reference says the Support URL must be a publicly accessible URL where users can get help. That’s the official version. The implicit version, learned from rejection patterns:

  1. The URL must load (no 404, no 5xx, no SSL cert errors).
  2. No login wall in front of the support information.
  3. Contact information must be visible above the fold on mobile.
  4. The page must work on iPhone, not just desktop. App Review checks on a phone.
  5. The URL stays live as long as the app is in the App Store. Updates that break the URL get flagged.

That last one matters more than people think. Apps get rejected on update years after first submission because the marketing site moved and the support URL now redirects to a 404.

The four most common Support URL rejections

The pattern: developer registers myapp.com, builds a marketing site with screenshots and pricing, drops a “Support” link in the footer, and uses myapp.com itself as the Support URL.

App Review opens the URL on iPhone, sees a hero image and a download button, scrolls, doesn’t find contact info above the fold, marks it as missing support information.

Fix: use a dedicated myapp.com/support URL, or surface contact info directly on the homepage (an email link in the header counts).

2. The Notion or Google Docs page

Free hosting via Notion is tempting. It works fine — until Notion has an outage during your App Review window, or until Notion’s UI changes and the page now requires a login click-through, or until the link format changes after a workspace rename.

App Review encountered an outage like this in 2023 and the rejection notes specifically mentioned “support URL did not load.” The fix was switching to a proper hosted page; the team lost 4 days waiting for re-review.

Fix: use a stable, self-controlled host. Even GitHub Pages or Netlify is more reliable than a Notion page on a custom domain.

3. The mailto: link as the entire page

Some developers use a Support URL like mailto:support@myapp.com (or a page that just contains a mailto link). Apple doesn’t accept either. The Support URL field needs to be an HTTP/S URL that loads a page with information on it; an email-only response makes the page not actually a “page.”

Fix: make the support page a real web page. The page can still primarily say “email us at support@myapp.com” — but it must be on the web, with text content visible to a crawler.

4. The 404 after a refactor

Six months after launch, the team rebuilds their marketing site on a new framework. The new site has a different URL structure. The Support URL field in App Store Connect still points at the old URL. The next app update gets rejected because App Review tested the URL and got a 404.

Fix: if you rename support URLs, update App Store Connect immediately, even if there’s no app update planned. App Review re-tests on every update — but Apple also crawls actively-listed apps for broken URLs.

A reference support page structure

Borrowing from Apple’s own developer support pages and from indie apps that consistently pass review on first submission, here’s what works:

Above the fold

  • Page title: “Support — <App Name>”
  • One sentence explaining what the app is.
  • Email address as a clickable mailto: link.
  • Optional phone number as a tel: link if you have one.
  • Support hours and timezone, e.g., “Mon–Fri 9am–5pm Pacific.”
  • Average response time, e.g., “We reply within 1 business day.”

If a user (or App Review) lands on the page, they should be able to find a way to contact you in under 5 seconds.

Below the fold

  • FAQ section with the 5–10 most common questions. This reduces inbound support load and shows App Review the page is substantive.
  • Link to the privacy policy, the terms of service, and the data deletion page (App Store Connect requires all three; having them linked from one place is convenient for App Review).
  • Mailing address if you’re a registered company (some App Store regions and dev programs require this).

Mobile-friendliness

App Review tests on iPhone. The support page should:

  • Render at 375px width without horizontal scroll.
  • Use system fonts or web-safe fonts. No giant font CDN load. Slow loads occasionally trigger rejection.
  • Make mailto: and tel: links tappable, not under a hover state.
  • No JavaScript dependencies for displaying contact info. If the contact info renders only after a JS bundle loads, App Review’s crawler may not see it.

What App Review usually doesn’t check (but should still be there)

  • Schema.org structured data for FAQ items. Doesn’t affect App Review, but helps Google show your support FAQs as rich results in search.
  • HTTPS only (no HTTP fallback). Should be obvious in 2026 but App Review will reject HTTP-only URLs.
  • A robots.txt that allows indexing. Doesn’t block App Review, but you want this page in search results when users Google “myapp support.”

Where OrbitKit fits

OrbitKit’s support page wizard captures the structure above:

  • Required: contact email.
  • Optional: phone, web URL, address, support hours, FAQ items (up to 20).
  • Renders as a mobile-first responsive page at https://your-domain.com/support with FAQ schema embedded.
  • Updates flow to the live URL in seconds — useful when you realize you forgot a piece of info five minutes before submission.

The Support URL is one of three URLs App Store Connect requires (Privacy Policy and User Privacy Choices being the others). OrbitKit handles all three from one wizard. See the support URL generator if you want to skip the page-building step.

Further reading