App Review Readiness Checklist: Website, Support URL, and Privacy Policy Setup for iOS Apps

Before you worry about wording, confirm that you have these URLs ready and publicly accessible (no login required):

1) App Website (App Store: App Information)

2) Support URL (App Store: App Information)

3) Privacy Policy URL (App Store: App Privacy and often required depending on your data practices) and also linked inside the app if appropriate for your use case (for example, in Settings/About).

Your app website does not need to be a marketing masterpiece. It does need to be real, reachable, and clearly tied to your app. A single-page site is acceptable if it answers basic questions and is not misleading.

Minimum content that typically prevents App Review friction:

App name and a one-sentence description that matches App Store text

At least 1–3 screenshots that reflect the current UI (avoid outdated screens) or a short feature list if screenshots are not available yet for a pre-release listing strategy (but do not misrepresent what the app does)【Note: keep consistent with your App Store screenshots】 Developer name or company name (the same one used in App Store Connect) and a way to contact you (email is fine) Links to Support and Privacy Policy pages (can be on the same domain) If your app requires an account: explain what is required to use the app and whether there is a free mode, demo, or guest access If your app has subscriptions: state that the app offers subscriptions and link to Terms (recommended) and Privacy Policy (required) to avoid confusion Example “App Website” copy you can adapt: Title: Focus Timer for iPhone Summary: Focus Timer helps you run simple Pomodoro sessions and track daily focus minutes. Highlights: Create timers, view daily stats, sync across devices (only if you truly sync) Contact: support@yourdomain.com Links: Support | Privacy Policy | Terms Common mistakes to avoid: Linking to a social profile instead of a real page (Apple may accept it sometimes, but it is fragile) A blank landing page, “Coming soon,” or a parked domain Broken HTTPS, expired certificate, or region-blocked hosting A site that describes features you removed from the build you submitted

Your support URL should lead to a page that answers questions without requiring the user to hunt for contact info. Reviewers often use it to validate that users can reach you and that you provide help for account/data issues if relevant.

Support page essentials:

A clear contact method: support email address, contact form, or both Expected response time (even a simple line like “We reply within 2 business days”) A short FAQ with the most likely questions (billing, account deletion, restoring purchases, syncing, troubleshooting) If the app uses Sign in with Apple or other login: add an “Account help” section If you offer subscriptions or IAP: include “How to manage or cancel subscriptions” with a link to Apple’s official subscription management instructions If you collect data or allow accounts: include “Request data access/deletion” instructions that align with your privacy policy Example Support URL structure (single page is fine): Section: Contact Email: support@yourdomain.com Section: FAQ Q: How do I restore purchases? A: In the app, open Settings > Restore Purchases. If it doesn’t work, email support with your Apple ID receipt email and device model. Q: How do I cancel a subscription? A: Subscriptions are managed in iOS Settings. See Apple’s instructions: https://support.apple.com/en-us/HT202039 Q: How do I delete my account? A: In the app, go to Settings > Account > Delete Account. If you cannot access the app, email support from the address used to create the account. Common mistakes to avoid: Support URL goes to a generic homepage with no contact Only a contact form that fails silently or requires login No guidance for account deletion when the app has accounts No billing/subscription help while selling subscriptions

Apple cares less about legal perfection and more about clarity and consistency: what data you collect, why you collect it, where it goes, and how users can make requests. Your privacy policy must not contradict your App Privacy disclosures in App Store Connect.

Privacy policy essentials (practical, review-friendly):

Who you are: developer/company name and contact email What data you collect: list categories in plain language (e.g., email, analytics events, purchase history, crash logs) Why you collect it: core functionality, support, analytics, security, payments Whether data is linked to the user or used for tracking Third parties: name key processors (e.g., Apple, Firebase, RevenueCat) only if you actually use them; otherwise describe categories without inventing vendors Data retention: a simple statement (e.g., “We retain account data until you delete your account”) User rights and requests: how to request deletion/access and how long it takes Children: whether the app is intended for children (or not) and what you do if minors are involved Effective date and change notice Example privacy policy snippets you can adapt (keep them true): Data we collect: We collect your email address when you create an account. We collect basic diagnostics (crash logs) to improve stability. If you enable analytics, we collect anonymized usage events such as button taps and screen views. How we use data: We use your email to authenticate your account and respond to support requests. We use diagnostics to fix bugs. Data sharing: We do not sell your data. We share data with service providers that help us operate the app (for example, cloud hosting and crash reporting) only as needed. Account deletion: You can delete your account in the app under Settings > Account. You can also email support@yourdomain.com to request deletion. Consistency checks to run before submitting: Your policy mentions analytics, but App Privacy says you collect nothing Your policy says “no data collected,” but the app uses login, crash reporting, or subscriptions Your policy says you do not track, but you run ads or cross-app tracking (if you do, disclose properly) The policy is a template with irrelevant sections that imply you collect data you don’t actually collect

Use this mini-flow right before you click Submit for Review:

1) Open each URL (Website, Support, Privacy) on mobile and desktop. Confirm it loads fast, has no 404s, and uses HTTPS. 2) Confirm Support page has a visible contact method without login. 3) Confirm Privacy Policy states what you actually do in the current build. 4) In App Store Connect, compare App Privacy answers to the policy line-by-line for anything user-identifiable (email, account ID), anything shared, and any tracking. 5) If your app has accounts: ensure you have a clear account deletion path (in-app if required by policy or platform expectations for your category) and that Support explains the fallback. 6) If you have subscriptions: ensure Support explains cancel/restore, and your website links to Privacy (and Terms if you have them). 7) Do a final “reviewer view”: pretend you have never heard of the app. Can you understand what it does and how to reach you in under 30 seconds?

You can host these pages a few different ways, and the best choice is the one you will keep updated as your app evolves.

Option A: Your own domain + simple static pages Pros: full control, fast, cheap Cons: you must maintain and ensure links never break Option B: A lightweight landing page builder that can generate a website plus support and legal pages Pros: faster to ship, consistent structure, easy to update across apps Cons: pick a tool that lets you use stable URLs and your branding If your goal is to quickly produce an iOS-ready landing page along with a support URL and privacy policy page that you can keep consistent for App Store submissions, MyAppDeck is relevant as a way to publish those essentials without building a full custom site. Regardless of tool, keep the checklist above as your source of truth: working links, clear support contact, and a privacy policy that matches your App Privacy disclosures.