Czy Twoja aplikacja potrzebuje regulaminu?

W internecie jest mnóstwo pewnych siebie tekstów, według których oba sklepy wymagają regulaminu. Przeczytaj strony samych sklepów, a zobaczysz, że nie to mówią. Warto więc rozdzielić trzy różne pytania, które kryją się w tym jednym.

Czy wymaga go Google Play?

Nie. Zasady Play dotyczące danych użytkownika (User Data policy) precyzyjnie określają, co i gdzie musi być podlinkowane: “All apps must post a privacy policy link in the designated field within Play Console, and a privacy policy link or text within the app itself.” (W tłumaczeniu: wszystkie aplikacje muszą umieścić link do polityki prywatności w przeznaczonym do tego polu w Play Console oraz link do polityki prywatności lub jej tekst w samej aplikacji). Polityka prywatności, dwa razy. Nie ma tam nic o regulaminie i nie ma na niego pola w konsoli.

Sekcja App content w Play Console prosi o adres URL polityki prywatności oraz, jeśli Twoja aplikacja ma konta, o adres URL usuwania danych. Regulaminu wśród nich nie ma.

Czy wymaga go Apple?

Tylko w jednym przypadku, za to częstym: aplikacje oferujące automatycznie odnawiane subskrypcje. Wytyczna 3.1.2 wymaga działających linków zarówno do polityki prywatności, jak i do Terms of Use (EULA), w samej aplikacji i w metadanych.

Nie musisz pisać tej umowy EULA. Apple publikuje standardową i możesz podlinkować ją zamiast własnej; w poradniku o Terms of Use (EULA) znajdziesz, gdzie trafia każda wersja.

W aplikacji bez subskrypcji Apple również nie wymaga regulaminu.

Dlaczego więc prawie każda aplikacja go ma?

Bo „sklep tego nie wymaga” i „nie potrzebujesz tego” to różne stwierdzenia. Regulamin to dokument, który odpowiada na pytania, których nie obejmuje żadna polityka prywatności:

• Kto może korzystać z aplikacji i co się dzieje, gdy ktoś jej nadużywa. Bez regulaminu nie masz zapisanej podstawy do zamknięcia konta.
• Co jesteś winien użytkownikowi, a czego nie. Tutaj znajdują się wyłączenia gwarancji i ograniczenia odpowiedzialności, i to one są powodem, dla którego regulaminy w ogóle istnieją.
• Co użytkownik jest winien Tobie: płatność, dopuszczalne korzystanie, treści, które przesyła.
• Które prawo ma zastosowanie i gdzie rozstrzyga się spory.
• Jak regulamin się zmienia i co się dzieje, jeśli któryś zapis jest niewykonalny.

Jeśli Twoja aplikacja ma konta, przyjmuje pieniądze, przechowuje treści użytkowników albo ma jakąkolwiek moderację, prędzej czy później będziesz potrzebować odpowiedzi na te pytania. Napisanie jej przed sporem jest tańsze niż po nim.

Co powinno się znaleźć w regulaminie aplikacji

Praktyczny zestaw sekcji, w kolejności, w jakiej zwykle najlepiej się czytają:

Sekcja	Co rozstrzyga
Korzystanie z aplikacji	Licencja na korzystanie, dopuszczalne użycie, co prowadzi do zamknięcia konta
Konta	Kto może się zarejestrować, Twoje prawo do zawieszenia, prawo użytkownika do usunięcia
Zakupy i subskrypcje	Rozliczenia, odnawianie, zwroty oraz to, że płatności przetwarza sklep, a nie Ty
Własność intelektualna	Do kogo należy aplikacja, do kogo należy to, co przesyła użytkownik
Wyłączenie i ograniczenie odpowiedzialności	Rdzeń dokumentu
Zmiany	Jak aktualizujesz regulamin i jak informujesz o tym użytkowników
Kontakt	Prawdziwy adres

Zwróć uwagę, czego tu nie ma: przetwarzania danych. To należy do polityki prywatności, a powielanie tego w dwóch dokumentach to prosta droga do tego, by zaczęły sobie przeczyć.

Czego unikać

• Kopiowania regulaminu innej aplikacji ze zmienionymi nazwami. To problem z prawem autorskim, i to w dokumencie, który opisuje cudzy biznes.
• Obiecywania tego, czego nie możesz zrobić. Regulamin, który mówi, że natychmiast usuwasz wszystkie dane albo gwarantujesz dostępność usługi, jest gorszy niż milczenie.
• Wskazywania jurysdykcji na chybił trafił. Prawo właściwe to prawdziwy wybór z prawdziwymi konsekwencjami.
• Chowania go. Jeśli regulamin jest dostępny tylko z linku, który usunąłeś przy ostatnim redesignie, niewiele da Ci jako obrona.

Pisanie go z asystentem AI

Asystent chętnie napisze regulamin, a typowy błąd jest taki sam jak przy polityce prywatności: poproszony o „terms of service for my app”, pisze średnią ze wszystkich regulaminów, jakie przeczytał: klauzule arbitrażowe, sąd w stanie, w którym nigdy nie byłeś, obietnice dotyczące dostępności. Poniższy prompt trzyma go przy standardowych sekcjach opisanych wyżej, każe mu przed pisaniem sprawdzić, co Twoja aplikacja faktycznie robi (logowanie, zakupy, treści użytkowników), i oznaczać to, czego nie wie, przez [confirm: …] zamiast to wymyślać. Jeśli aplikacja przyjmuje płatności na iOS, musi zawierać link do standardowej umowy EULA Apple.

Skopiuj go w całości. Zastąp fakty w nawiasach kwadratowych na górze albo zostaw je i pozwól asystentowi o nie zapytać.

You are helping me write the terms of service for my mobile app. They will be published as a web page on AppFoyer, next to the app's privacy policy, and linked from the app and its store listings. They should be short, standard and true for this app.

## About the app

- App name: [app name]
- Developer / company: [developer or company name]
- Support email: [support email]
- Platforms: [Android, iOS or both]
- Store listings: [store listing URLs, or "not listed yet"]
- Where these terms will be published: [your AppFoyer site URL]/terms
- What the app collects, as I declared it: [what the app collects — e.g. account info, analytics, ads, crash reports, location, purchases, or nothing]
- Account deletion page: [your AppFoyer site URL]/account-deletion (only if the app has user accounts)
- Country whose law applies: [country, if you have one]

## Step 1 — find the facts

If you can read this app's source code, read only its build, manifest and store-metadata files — for example `build.gradle(.kts)`, `gradle/libs.versions.toml`, `AndroidManifest.xml`, `Podfile.lock`, `Package.swift`, `Info.plist`, `PrivacyInfo.xcprivacy`, `pubspec.yaml`, `package.json`, `app.json`. Do not open `.env` files, keystores, credentials or any other secrets, and do not change any file.

From them, work out only what changes the terms:

- whether users sign in or create accounts (Firebase Auth, Sign in with Apple, Google Sign-In and the like);
- whether the app sells in-app purchases or subscriptions (StoreKit, Google Play Billing, RevenueCat and the like);
- whether users can post, upload or send content that others see (chat, comments, photos, profiles);
- whether the app shows ads or links to third-party services.

Show me that short list with the file each fact came from and ask me to confirm it. If you cannot read the code, ask me these four questions instead.

## Step 2 — ask only what you cannot know

Then ask me, in one short numbered list, and wait for my answers:

1. The minimum age to use the app.
2. Whether the app is free to use for personal purposes only, or also for business use.
3. If users can post content: what is not allowed, and whether I may remove it or close accounts.
4. Anything else you could not determine.

Never guess. Where I do not know an answer, write `[confirm: …]` in the text instead of inventing one.

## Step 3 — write the terms

Sections, in this order, leaving out any that do not apply: Acceptance of these terms · Use of the App · Accounts · Purchases and subscriptions · User content · Intellectual property · Third-party services · Disclaimer and limitation of liability · Termination · Changes to these terms · Governing law (as the placeholder below) · Contact.

- Standard, plain-language terms for a mobile app. Keep each section to a few sentences; this is not a contract negotiation.
- Purchases and subscriptions: payments are processed by the app store, prices are shown before purchase, subscriptions renew automatically until cancelled in the store account settings, refunds follow the store's policy.
- Disclaimer and limitation of liability: the app is provided "as is", and liability is limited "to the extent permitted by law".
- Do not describe how personal data is handled; that is the privacy policy's job.
- Do not promise what I cannot guarantee — uptime, instant deletion, error-free operation.
- Do not invent a company address, a court, arbitration or a jurisdiction — use `[confirm: …]`.
- Do not copy another app's terms.
- Start with `# Terms of Service`, then the line `_Last updated: [today's date]_`.
- Write these placeholders exactly as shown, never the values — they are filled in from my settings when the page is published: `{{app_name}}`, `{{developer_name}}`, `{{support_email}}`, `{{public_url}}`.
- In the Contact section, write the address as `[{{support_email}}](mailto:{{support_email}})`.
- Refer to the privacy policy as `[Privacy Policy]({{public_url}}/privacy)` instead of describing data handling here.
- If the app has user accounts, say in the Accounts section that users can request account deletion at `[{{public_url}}/account-deletion]({{public_url}}/account-deletion)`.
- Mandatory if the app is on iOS and has any in-app purchase or subscription — declared above, found in the build files or confirmed by me: in the Purchases and subscriptions section, include this sentence unchanged: For the iOS version, Apple's standard [Licensed Application End User License Agreement](https://www.apple.com/legal/internet-services/itunes/dev/stdeula/) applies to your use of the App. Never leave it out when the app takes payments.
- For governing law, write the line `{{governing_law}}` on its own and nothing else — it becomes the governing-law section when a country is set in my settings, and disappears when none is.
- End with this paragraph, unchanged:

  _This page was generated from a template provided by the hosting platform and completed by the app developer. It is not legal advice. The developer named above is solely responsible for its accuracy and for complying with the laws that apply to them._

## Format — this is pasted into a Markdown editor

- Reply with the finished terms only, as Markdown inside one ```markdown code block, with nothing before or after it.
- CommonMark only: headings, paragraphs, lists, bold, italics and links. No tables, no HTML, no images, no footnotes.
- Links only to `{{public_url}}` (for example the privacy policy), to Apple's EULA as above and to the support email. Any other link is shown as plain text on the published page, so leave it out. No link shorteners, no download links.

Prompt jest napisany pod strony publikowane w AppFoyer, dlatego prosi o symbole zastępcze w stylu {{app_name}} i kończy się naszym zastrzeżeniem. Jeśli publikujesz gdzie indziej, usuń te linie w Step 3 i poproś zamiast tego o konkretne wartości. W sprawie polityki prywatności zajrzyj do poradnika Pisanie polityki prywatności z asystentem AI.

Co robi tu AppFoyer

Regulamin to jedna z pięciu stron, które generujemy, obok polityki prywatności, strony wsparcia i strony usuwania konta. Szablon obejmuje opisane wyżej sekcje, wypełnia nazwę Twojej aplikacji, nazwę dewelopera, adres wsparcia i linki do sklepów, a także dodaje sekcje o subskrypcjach (w tym link do standardowej umowy EULA Apple), gdy wskażesz, że aplikacja sprzedaje subskrypcje na iOS.

Edytor regulaminu w panelu ma też panel Write it with your own AI (Napisz to z własnym AI): powyższy prompt, już wypełniony danymi Twojej aplikacji. Uruchom go w dowolnym asystencie, wklej odpowiedź, przeczytaj podgląd, opublikuj.

Checklista zgodności zgłasza tę stronę, dopóki nie zostanie opublikowana, a w przypadku aplikacji z subskrypcjami, dopóki link do EULA rzeczywiście się na niej nie znajdzie.

Jak każda generowana strona, jest to szablon, który uzupełniasz i za który odpowiadasz, a nie porada prawna. Jeśli Twoja aplikacja ma do czynienia z pieniędzmi, danymi o zdrowiu lub dziećmi, daj ją do przeczytania prawnikowi.

Źródła oficjalne

• User Data policy — Pomoc Google Play. Powyższy cytat pochodzi z tej strony.
• App Store Review Guidelines — Apple. Sekcja 3.1.2 to zasada dotycząca subskrypcji.
• Licensed Application End User License Agreement — standardowa umowa EULA Apple.