App Store Support URL & Privacy Policy Requirements (2026)

Apple URL fields: what each one is for

Apple defines the Privacy Policy URL at the app-information level. Its current App Privacy reference says the URL is required for all apps, while the broader App Information reference specifically describes it as required for iOS and macOS apps and handles tvOS privacy text separately. Use the current fields shown for your platform in App Store Connect and do not assume one platform’s form exactly matches another.

The Support URL belongs to platform version information. Apple says it is required, can be localized, appears on the App Store for users who downloaded the app, and must lead to actual contact information so users can reach the developer about issues, feedback, and feature requests. The Marketing URL is optional and can point to the page where users learn more about the app.

What an App Store Support URL should contain

Apple’s platform-version reference says the Support URL must lead to actual contact information, listing examples such as legal address, email address, or telephone number as local law may require. The page should clearly identify the app and publisher, explain how to request help, and give users enough context to choose the right channel.

A `mailto:` link by itself is fragile as a support destination: it provides no troubleshooting context, does not establish publisher identity, and may fail in review or user environments without a configured mail client. A public HTTPS support page can still use email as the main contact method while also offering response expectations, common issues, account or deletion paths, version information, and links to Privacy and Terms.

• App name, publisher name, and a visible support heading.
• Monitored email address or another real contact mechanism.
• Legal contact details where applicable to the publisher and market.
• Links for account access, deletion, billing, or security issues when relevant.
• Current Privacy Policy, Terms, store listing, and app version context.
• A localized page or clear language selector when support is offered in several languages.

What the privacy policy page needs to accomplish

The policy must describe the actual app and its data handling, including relevant third-party SDK behavior. Apple’s App Privacy disclosures and the public policy should not contradict one another. Google’s User Data policy requires the developer or company named in the store listing—or the app itself—to appear in the policy, along with a privacy contact mechanism, the personal and sensitive data accessed, collected, used, or shared, the parties with which it is shared, secure handling procedures, and retention and deletion practices.

Do not copy a generic policy without reconciling it with analytics, advertising, authentication, payments, crash reporting, cloud storage, support tooling, and account deletion. A generator can help structure a draft, but the publisher remains responsible for accuracy and applicable law. Get qualified legal review when the app, audience, data, or jurisdiction makes that necessary.

Google Play privacy URL requirements

Google’s current Developer Program Policy says all apps must post a privacy policy link in the designated Play Console field and a privacy policy link or text inside the app. It also says apps that do not access personal and sensitive user data must still submit a privacy policy.

Google requires the destination to be an active, publicly accessible, non-geofenced URL; it must not be a PDF and must be non-editable. Label the page clearly as a privacy policy and keep it reachable without an account, paywall, expired share token, or region restriction. The Data safety form is a separate disclosure surface, so verify that the form, policy, SDK inventory, permission use, and in-app behavior agree.

Can one landing page host all required destinations?

One domain can host the app landing page, Support, Privacy, Terms, and user-choice pages, but use stable direct URLs for each purpose. A store reviewer or user should not have to open a marketing homepage and hunt through a carousel or menu to find the policy. Direct paths such as `/privacy`, `/support`, and `/terms` are easier to validate and maintain.

Keep these pages connected through the footer and consistent publisher identity. If one publisher has several apps with materially different data practices, use app-specific policies or clearly separated sections and direct anchors. Avoid silently changing the content behind a published URL to describe a different app.

Common URL failures before review

Most failures are operational rather than visual: the URL is private, redirects unexpectedly, depends on a login, returns an error in another country, identifies the wrong publisher, omits a contact path, or contradicts the store’s data disclosures. Test the final production URL in a private browser session and from a phone before submitting it.

• Placeholder, parked, staging, localhost, or expired preview URL.
• Public homepage with no direct policy or support destination.
• Google Play privacy policy delivered as a PDF or editable shared document.
• Policy names a template company but not the app or listed publisher.
• Support page has no monitored contact method.
• HTTP, certificate, redirect-loop, robots, or geography problems.
• Data safety or App Privacy answers disagree with the public policy.
• Account deletion instructions are missing where the app and platform rules require them.

Submission-day verification checklist

Open every URL from the exact value saved in App Store Connect or Play Console. Confirm the final response, title, publisher identity, language, mobile layout, and contact path. Save a dated copy of the published policy and the store disclosures that were submitted so later SDK or product changes can be reviewed against a known baseline.