Apple / Google Play links: Privacy, Terms, Support
When you publish games on the Apple App Store or Google Play, the platforms ask for public links to certain pages on your website. It's not enough for the documents to exist in a Google Doc, a private PDF or an internal folder. They must be public, accessible online, at clear URLs you can paste into the platform forms.
Good examples:
company.ro/privacycompany.ro/termscompany.ro/supportcompany.ro/contact
Heads up: the templates and examples here are designed for free-to-play (F2P) mobile games. They cover typical F2P things, analytics, accounts, virtual currency, purchases, battle pass, cosmetics, live ops, sometimes ads. If your game is different (paid premium, no accounts, no analytics, B2B, etc.), you need to adapt them seriously. Don't use them as a final document without review.
These pages matter because the platforms want users to be able to find out who operates the game, what data is collected, how to get support and what rules apply. Apple requires a Privacy Policy URL for iOS and macOS apps (including data collected by third-party partners), and the developer is responsible for keeping the information accurate and up to date. Google Play uses this information for trust, verification and transparency toward users.
The links usually required
| Link | Where you use it | Why it matters |
|---|---|---|
| Privacy Policy | Apple, Google Play, website, sometimes SDKs / third-party services | Explains what data the game collects, why, through which SDKs, and how the user can request information or deletion. |
| Terms & Conditions | Website, store listing, support, accounts, payments, multiplayer, live ops | Defines usage rules, purchases, virtual currency, bans, refunds, ownership and limitations. |
| Support / Contact URL | Apple / Google Play, website, store pages | A clear contact path for bugs, refund issues, moderation appeals, accounts or technical problems. |
| Privacy choices / Data deletion URL | Sometimes, especially with accounts, user data, analytics, ads or strict regions | Helps users exercise their rights over personal data. |
Why they're required
They aren't just "formalities", they become part of the game's legal and operational infrastructure. For a mobile game, the privacy policy and terms must explain:
- who the company operating the game is;
- what data the app collects (and what the SDKs collect automatically);
- whether there are accounts, analytics, crash reports or device identifiers;
- whether there are purchases, premium currency, battle pass or cosmetics;
- whether there is chat, usernames, social features or moderation;
- whether there are ads, rewarded ads or ad measurement;
- how users can request support or data deletion;
- what rules apply for cheating, abuse, bans, refunds and virtual items.
For a free-to-play game these documents are even more important, because the F2P model frequently involves analytics, events, progression, purchases, virtual currency, live ops, battle passes, cosmetics and sometimes ads.
Why they should be on the company domain
Ideally you keep these links on the company domain, not a random domain or a temporary link:
pixelforge.org/privacypixelforge.org/termspixelforge.org/support
The reason is coherence. If the company is Pixelforge SRL, the Google Play account is on a company email, the website is on the company domain, and the privacy policy is there too, everything looks clean and easy to verify. It matters for developer account verification, user trust, platform review, support, internal audit and a potential investment, acquisition or account transfer.
A useful Privacy Policy generator
A good starting point is the privacy policy generator for mobile apps: app-privacy-policy-generator.firebaseapp.com. It quickly generates a privacy policy structure and is useful especially for your first game, to see which sections usually appear.
The generator doesn't know how your game works. Check manually: which SDKs you integrated, what data each collects, whether you have login/accounts, purchases/subscriptions, ads/rewarded ads, chat/multiplayer/moderation, analytics/crash reporting, whether the game targets children, and which regions your users come from (EU, US, etc.). Don't treat it as a final document without review.
Third-party SDKs and services
The templates include sections for SDKs common in mobile games:
- Google Play Services;
- Apple App Store / Apple services;
- Google Analytics for Firebase;
- Firebase Crashlytics;
- Facebook / Meta services;
- RevenueCat;
- AppLovin (if you use ads or rewarded ads).
Adjust the list to match your real build. Don't keep SDKs you don't use, and don't omit SDKs that collect data. The privacy policy, Google Play's Data Safety form and Apple's App Privacy in App Store Connect must be consistent with each other. A common mistake is a generic privacy policy that says something different from what you declared in Data Safety / App Privacy, that causes problems at review and in later checks.
Document templates (F2P examples)
Starting points for a free-to-play mobile game. Adapt them to your actual game before publishing:
What to watch out for
Before you publish the links in the Apple App Store or Google Play:
Practical recommendation
Prepare these pages before you start publishing:
- Privacy Policy;
- Terms & Conditions;
- Support / Contact;
- Data deletion / Privacy request, if you have accounts or collect personal data;
- the company / studio main page.
Then use simple, permanent URLs: /privacy, /terms, /support, /contact.
Don't change these URLs often. Once you've put them in Apple, Google Play, SDK dashboards or partner accounts, any structural change can lead to dead links or verification problems.
Next step
Prepare the content of the Privacy Policy and Terms & Conditions pages and put them at fixed URLs on your domain. Save the final links in My Own Company Details, so you have them handy for the platform forms.