What happens if I don’t have a support website or privacy policy URL for my app – is that okay?

Submitting an iOS app without a support website or privacy policy URL is almost always a fast‑track to rejection. In my experience, reviewers look for two signals: can users get help, and do you handle data responsibly? Fortunately, you can ship a lean, compliant setup in under an hour.

The short answer: it’s not okay to skip these URLs. Apple expects a working support page and a public privacy policy. I’ll show the exact lightweight pages I’ve used with founders and enterprise teams to pass review on the first try.

Why Apple cares about these URLs

• User trust: people need a way to reach you and understand data use.
• Policy alignment: matches App Store Review Guidelines and regional laws.
• Risk control: reduces refunds, disputes, and low ratings.

Short walkthrough

The minimum viable setup that passes review

Support page essentials

• Contact method: monitored email address and/or form.
• Quick FAQ: sign‑in, subscriptions, refunds, data requests.
• Privacy link: visible and accessible without login.

Privacy policy essentials

• What you collect: categories like email, usage data, purchase info.
• Why you collect: core features, analytics, crash reporting.
• How long you keep data and how users can request deletion/export.

Copy templates you can adapt

Support page CTA

Need help with [App Name]? 

• Email us: support@[domain].com 
• Visit the FAQ for sign-in, billing, and data requests. 
• To request data export or deletion, email privacy@[domain].com

Privacy policy intro

We built [App Name] to [purpose]. We collect only what we need to run the app, improve reliability, and support you. This policy explains the data we collect, how we use it, and your choices (export, correction, deletion).

Settings that matter for GDPR/PDPA/GR71

These small additions materially reduce risk and review friction in Europe and Southeast Asia.

• Data rights: add instructions for access, correction, deletion (GDPR Art. 15–20).
• Regional contact: routable inbox for privacy requests; avoid web forms only.
• Consent: if using analytics/ads, show a region‑aware consent banner.
• Disclosures: list third‑party SDKs and purposes (analytics, crash, ads).

Further reading: OWASP MSTG, Google Play Data safety, GitHub privacy statement.

What if I truly can’t publish a full site yet?

• Ship a simple static page for support and a plain‑text privacy policy.
• Host on your domain; avoid Notion or Google Docs if possible.
• Keep both pages public, responsive, and linked from your app footer.

Internal links to help you prepare

• How I scan apps before submission
• Security best practices checklist
• Compare Android disclosure requirements

Key takeaways about missing support or privacy policy URLs

Don’t submit without them. You’ll likely be rejected and lose time. Publish a lean support page and a clear privacy policy, then link both in App Store Connect.

For GDPR/PDPA/GR71 regions, include data rights and contact details. These additions materially reduce review friction and user complaints.

App privacy checklist

Read more

AI code vulnerability scanning

Read more

Mobile security quick wins

Read more

Android security scanner

Read more

FAQ

Can I submit without a privacy policy if I don’t collect data?

Even if you collect very little, publish a short policy stating what you collect (if anything) and how users can contact you. It strengthens trust and reduces review friction.

Is a PDF privacy policy acceptable?

Yes, but a mobile‑friendly HTML page is better for accessibility and updates.

Do I need a company address?

Not mandatory for Apple review, but include a contact method and your legal entity details if you have them. It increases credibility.