App Store Support URL and Marketing URL
The support URL is required and has to reach a human. The marketing URL is optional. If you provide either, it has to load.
Quick answer
What is the App Store support URL?
The support URL is required. It must load and lead to real contact information, such as an email, phone, or address, so a person can reach you. The marketing URL is optional, can be localized, and must load if you set it. The privacy policy URL is a separate required field for iOS and macOS apps.
On this page
The App Store support URL is the page a customer opens when something breaks. It is required. The marketing URL is the page you hope they open when they want the story of the app. It is optional. Apple treats them as different fields. A privacy policy URL is a third field, and it is required for iOS and macOS apps. Mixing the three into one dead link is a good way to fail review or to abandon the people who paid you.
Apple’s platform version information defines the support URL and the marketing URL. The product page overview is at Creating Your Product Page . What the privacy URL must contain is in the privacy policy URL guide. Launch order is in the App Store launch checklist.
Support has to reach a person
Apple’s wording is direct. The support URL is the support website you plan to provide, shown on the App Store to people who have downloaded the app. It must lead to actual contact information, a legal address, email address, or telephone number, as local law may require, so users can reach you about app issues, feedback, and feature requests. Specify the whole URL, including https.
A page that loads and only says “thanks for your interest” does not meet that bar. A chatbot with no address and no inbox does not meet it. A mailto link can be enough if it is a mailbox a human reads. Put the address on the page in text as well, so someone can copy it if the link fails. The point is that a stranger can reach you, not that you own a stylish help center.
Marketing URL is optional and localizable
Apple describes the marketing URL as the website where users get more information about the app. Include the protocol. The field can be localized, so a Japanese storefront can point at a Japanese page and the English storefront can point at an English one. If you do not have that page, leave the field empty. Do not paste the support URL into both fields unless that single page truly does both jobs and loads.
The marketing page can show the product, a few screenshots, and how to buy. It should not contradict the App Store description. If the site says the utility is free and the app is paid, you have a metadata problem, not a branding problem. Update the site when the price or the feature set changes. Review can look at URLs you put on the version.
Worked example: a paid utility
The app is a one-time purchase that renames a batch of files on a Mac and an iPhone. There is no account. Support is an email. The right support URL is a short page on your domain that names the app, shows the email in text, and says what to include in a message: the OS version and what the rename did wrong. That page loads without an account. You read the mailbox.
The marketing URL can be the product page on the same site, with a download link back to the App Store and three honest screenshots. It is optional. If the only page you have is the support page, submit the support URL and leave marketing blank until the product page exists. Do not point marketing at a parked domain. Do not point support at a Twitter profile that you might lock.
| Field | Required? | What belongs there |
|---|---|---|
| Support URL | Yes | A page that loads and shows a real way to reach you |
| Marketing URL | No | More about the app. Localizable. Must load if you set it |
| Privacy Policy URL | Yes on iOS and macOS | The policy, not the support inbox. A separate guide |
| A social profile | Not as support | Fine as a link on the page, not as the only contact |
Support is required and must reach a human. Marketing is optional. Privacy is a different required URL. Every URL you submit has to load.
Privacy is not the support page
The privacy policy URL links to your privacy policy. Apple marks it required for iOS and macOS apps. A tvOS app also needs the privacy policy text in the Apple TV field. Do not paste the support email page into the privacy field and call it done. The policy has to name the developer, what is collected, why, and how to contact you. The support page can link to the policy. They are not the same document.
The nutrition label in App Store Connect has to match that policy. That match is covered in app privacy details. A support URL that says you collect nothing, while the label says you collect purchases, is a contradiction review can reject. Keep the sentences aligned.
What review is looking at
Reviewers open links. A support URL that 404s, redirects to an unrelated store, or sits behind a password with no public email is a problem. So is a marketing site that shows features the binary does not have. Guideline 2.3 is about accurate metadata. A URL is metadata. If the paid utility’s site still says “coming soon” for a feature you screenshot, fix the site or the screenshot before you resubmit.
Localize the support page when you localize the app. A Spanish listing that lands on English-only contact info is a weak promise if you claimed Spanish support. You can still offer English support if you say so plainly. Do not hide the language. The marketing URL can differ by localization. The duty to load does not differ.
Keep the page boring and reachable
You do not need a ticket system for a paid utility with one developer. You need a URL that resolves, an address a human reads, and a sentence about what the app is. Put that URL on the version, test it, and do not let the domain expire after launch. Customers who cannot reach you will use the review thread instead, and those reviews are public.
The description can mention how to get help, but it should not be the only place the email appears. The support URL is the field Apple shows for that job. Write the description for what the utility does. Keep the inbox on the support page. When the email changes, update the page and confirm the old address forwards, so last year’s customers are not writing into the void.
Set the support and marketing URLs
Do this before you submit the version, not after review asks where the link went.
Publish a support page that names a human path
Create a page that loads over https without an account. Include an email, a phone number, or a legal address in text, whichever you will actually answer. For the file-rename utility, an email plus what to send is enough. Read Apple’s requirement again: contact information so users can reach you about issues, feedback, and requests.
Open it in a private window
Load the final URL while logged out. Confirm it is not a 404, not a staging site, and not a login wall. Click the mail link. Send yourself a message and confirm it arrives. If you set a marketing URL, repeat the test. Optional still has to resolve.
Leave marketing blank if you have no site
Paste the marketing URL only when that page explains the app and matches the binary. Localize it if you have a real translated page. If you do not, leave the field empty rather than pointing every language at an English teaser that overclaims. Do not duplicate a broken URL to look complete.
Point privacy at the policy, not the inbox
Set the privacy policy URL to the policy document. It is required for iOS and macOS. It should name you, what you collect, why, and how to contact you. The support page can link to it. Do not reuse the support URL unless that exact page is the policy, which for a real policy it usually is not.
Re-check both links on the version you submit
After you paste the URLs into App Store Connect, click them from the version page. Submit only when support loads and shows contact info, and when marketing either loads or is empty. When the domain or the inbox changes later, update the field in the same week. A listing that points at last year’s host is a broken support promise.
Key takeaways
- The support URL is required and must show a real way to reach you.
- The marketing URL is optional, can be localized, and must load if you provide it.
- Include the full URL with https. Test it logged out.
- The privacy policy URL is a separate required field on iOS and macOS.
- A paid utility can use a plain email page. It cannot use a dead link or a locked social profile as the only contact.
Frequently asked questions
Is the marketing URL required?
No. Apple describes it as the website where users get more information, and it is not the required support field. Leave it empty if you do not have a page. If you fill it in, the URL has to include the protocol and it has to load. It can be localized per language. Do not paste a parked domain to make the form look finished.
Can the support URL be a mailto link?
Apple requires a URL that leads to actual contact information, including an email address. A normal https page that shows the email in text is the safer choice, because a reviewer and a customer can see it without a mail app. If you use a mailto link, test it, and still show the address in text on a page that loads. An unread inbox does not count as contact.
Can support and marketing be the same URL?
Only if that one page both explains the app and shows how to reach a human. Many small utilities do this. The privacy policy should still be its own URL if the policy is a separate document. Do not point all three fields at a homepage that never mentions contact or privacy. Each field has a job.
What if my support site is down during review?
Fix it before you submit, or expect the reviewer to be unable to confirm the link. A URL that fails during review is a metadata problem you can avoid by clicking it yourself. After launch, downtime means customers use public reviews to ask for help. Keep the domain renewed and the page on a host you control.
Does the support URL replace a privacy policy?
No. The privacy policy URL is required for iOS and macOS apps and should open the policy. The support URL is for product help and feedback. They can link to each other. A support page that never states what you collect does not satisfy the privacy field. Read the privacy policy guide before you paste the same link into both boxes.
Keep reading
Privacy Policy URL for App Store and Play
The policy has to name you, what you collect, why, and how to reach you. It has to match the nutrition label and the Data safety form.
App Store Metadata Rejection: What Triggers It
Guideline 2.3 is accurate metadata. A “#1 workout” line and a competitor’s name in the keyword field are the kind of thing that gets a fitness app sent back.
App Store Launch Checklist: From Screenshots to First Users
A practical launch plan for indie app developers: get your listing compliant, make screenshots convert, recruit useful early feedback, then improve with evidence instead of post-launch guesswork.
App Privacy Details: What to Declare
The nutrition label is three buckets you fill in App Store Connect. For a hiking app with on-device trails and optional iCloud, tracking stays empty unless you actually track.
How to Write an App Store Description That Converts
Apple’s description is 4,000 characters of conversion copy, not a keyword essay. Structure, first-sentence rules, and why a “description generator” still needs you.
Free tools that help here
Top App Store Apps
Track Apple App Store top charts across 30 countries. View top free and paid rankings for ASO research - updated from Apple's public RSS feed.
ASO Character Counter
Count characters for every App Store and Google Play metadata field against exact store limits. Live counts and over-limit warnings - nothing gets truncated at submission.
Point support at a page a person answers
Publish a URL that loads, shows how to reach you, and matches the paid utility you actually sold.
Try AppGrowthKit for Free