When I'm about to submit a Rork-built app to the App Store, the last thing I worry about is the code. The thing that quietly delays my releases, every single time, is the privacy policy. My first few Rork apps were rejected under Guideline 5.1.1 - Privacy - Data Collection and Storage simply because I'd reused a vague template I found online without thinking through what my app actually sent over the network.
This article is the working English template I now reuse for every Rork app I publish, plus the spots where I see other indie developers get tripped up. It assumes a typical Rork stack: Supabase for auth, Stripe for payments, OpenAI for AI features, and AdMob for ads. Strip out whatever you don't use.
Why Rork apps need a custom privacy policy
Rork handles a lot for you, but it does not generate a privacy policy. That's actually fair — only you know what your specific app collects. The tricky part is that Rork apps often ship with third-party calls that you didn't write directly. From my own experience:
- The moment I added an AI chat feature, every prompt was being sent to OpenAI.
- An image-generation feature I dropped in routed requests through Replicate.
- Just enabling Supabase auth meant emails and IP addresses were being logged on Supabase's side.
All three count as "transmitting personal data to third parties." Skip them in your policy and the App Store reviewer will catch it. The good news: if you honestly list whatever services your Rork project uses, the template approach below clears review almost every time.
Related: How to fix Privacy Manifest errors in Rork app review
Start by mapping the five App Store data categories
In App Store Connect's "App Privacy" section, you declare what you collect under these top-level categories. Writing your policy in the same order makes it much easier for the reviewer to map sentences in your policy to the declarations in App Store Connect.
- Contact info: email, name, phone number
- User content: text, images, audio that users create inside the app
- Identifiers: user IDs, device IDs (IDFA, etc.)
- Usage data: taps, views, purchase history
- Diagnostics: crash logs, performance metrics
I now write down "what does my app collect under each of these?" before drafting a single sentence. Forcing that order at the start of the process eliminates 90% of the omissions that lead to rejection.
A copy-and-paste English template (typical Rork stack)
Below is the template I use when shipping a Rork app with Supabase auth, Stripe payments, OpenAI for AI, and AdMob for ads. Delete any block whose service you don't actually use.
# Privacy Policy
Last updated: April 27, 2026
[App Name] ("the App"), provided by [Operator Name] ("we", "us"),
respects user privacy. This Privacy Policy explains how we handle
personal information.
## 1. Information We Collect
The App may collect the following information:
- **Account information**: email address, username (via Supabase Auth)
- **Payment information**: purchase history, subscription status (via Stripe;
we never store credit card numbers on our own servers)
- **AI usage logs**: prompts you submit and AI-generated responses
(via the OpenAI API)
- **Advertising identifiers**: identifiers used to deliver relevant ads
(via AdMob, only with your consent)
- **Crash and usage statistics**: device model, OS version, and crash logs
## 2. How We Use Your Information
We use this information only for the purposes below:
- Account authentication and identity verification
- Providing paid features and managing billing
- Generating AI responses and improving service quality
- Diagnosing bugs and improving app performance
- Detecting violations of our Terms of Service
## 3. Third-Party Services
We send the minimum information necessary to the following services:
- Supabase Inc. (USA): authentication and database
- Stripe, Inc. (USA): payment processing
- OpenAI, L.L.C. (USA): AI response generation
- Google LLC (USA): AdMob and Google Analytics
You can review each service's privacy policy here:
- [Supabase Privacy Policy](https://supabase.com/privacy)
- [Stripe Privacy Policy](https://stripe.com/privacy)
- [OpenAI Privacy Policy](https://openai.com/policies/privacy-policy)
- [Google Privacy Policy](https://policies.google.com/privacy)
## 4. International Data Transfers
The services listed above are headquartered in the United States.
By using the App, you acknowledge that your personal information
may be transferred outside of your country of residence.
## 5. Your Rights
You can exercise the following rights at any time:
- Access, correct, or delete your account information
- Opt out of receiving promotional emails from us
- Request deletion of your data (please contact us at [contact email])
## 6. Contact
If you have questions about this Privacy Policy, please reach out to:
[Operator Name] / [Contact email]The fastest path is to host this on GitHub Pages or a public Notion page, then paste the URL into App Store Connect's "Privacy Policy URL" field.
Three things Rork developers commonly miss
When I help someone debug a rejection, these are the three places I check first.
1. AI prompts count as user content
If your Rork app has an AI chat feature, the prompts users type are both "user content" and "data sent to a third party." Omit this and you will be rejected almost without exception. I now include a bold sentence in my in-app onboarding too:
Heads up: When you use AI features, your input is sent to OpenAI servers to generate the response. Please avoid entering sensitive personal information.
2. Stripe receipt emails count as contact info
Stripe sends receipt emails to your customers by default. That email address has been handed to Stripe, which means it must be disclosed as a third-party transfer. There's basically no way around it, so just keep Stripe in the list.
3. AdMob brings IDFA along for the ride
If your free app uses AdMob, you must show the App Tracking Transparency dialog. Your privacy policy must mention that "advertising identifiers may be collected," and your app must request ATT consent at launch. Read this together with the Rork Privacy Manifest fix guide to get both layers right.
Always provide a localized version too
App Store reviewers are distributed around the world. If your policy is only in Japanese (or only in your local language), you may get a "please provide an English version" follow-up that costs you another review cycle. After I shipped a few Japan-only apps, I now always pair the local-language version with an English translation hosted at the same path under /en/.
When writing the English version, sticking to the section headers reviewers already recognize — "Privacy Policy," "Effective Date," "Information We Collect," "How We Use Your Information," "Third-Party Services," "Your Rights," "Contact Us" — saves time. Don't translate literally; rewrite to match conventional English phrasing.
Maintenance: when to update the policy
A privacy policy is not "write once and forget." I update mine whenever any of the following happens:
- I add a new third-party service (for example, dropping in PostHog for analytics)
- The location or retention period of stored data changes
- The applicable law changes (for example, an amendment to the EU Digital Services Act)
When I update, I always change the "Last updated" date and, for material changes, push an in-app notice to existing users. Skipping that notice makes it much harder to defend yourself if a user later claims they didn't consent.
For the broader release picture, the Rork Max App Store review guide walks through what to verify in the final pre-submission checklist.
Just ship one with the template
Privacy policies sit at the intersection of code and law, and that combination invites the trap of "I'll publish it once it's perfect." In practice, the template above — with [App Name] and [Contact email] filled in and the file hosted on GitHub Pages — has cleared App Store review for almost every Rork app I've shipped.
So pick one app you're sitting on, drop this template in, and fill the URL into App Store Connect's Privacy Policy field today. Just having that field filled removes a surprising amount of the friction between "almost ready" and "submitted." Treat the template as the foundation, then refine it as your app evolves.
If you want to go deeper into the implementation side of personal data handling, the Rork app privacy and data protection guide is a natural next read — it covers what you should be doing in code to back up the promises in your policy.