Чи потрібні вашому застосунку умови використання?

В інтернеті багато впевнених текстів про те, що обидва магазини вимагають умов використання. Прочитайте власні сторінки магазинів — і побачите, що вони кажуть інше, — тож варто розділити три різні запитання, що ховаються в цьому одному.

Чи вимагає цього Google Play?

Ні. Політика Play щодо даних користувачів (User Data policy) конкретно визначає, що і де треба вказати: “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.” (Переклад: «Усі застосунки мають розмістити посилання на політику конфіденційності у відповідному полі в Play Console, а також посилання на політику конфіденційності або її текст у самому застосунку».) Політика конфіденційності, двічі. Про умови використання там нічого не сказано, і поля для них у консолі немає.

Розділ App content у Play Console просить URL-адресу політики конфіденційності і, якщо у вашому застосунку є облікові записи, URL-адресу для видалення даних. Умов серед них немає.

Чи вимагає цього Apple?

Лише в одному випадку, і він поширений: застосунки з автоматично поновлюваними підписками. Правило 3.1.2 вимагає робочих посилань і на політику конфіденційності, і на Terms of Use (EULA) — у самому застосунку та в метаданих.

Писати цю EULA самому не обов’язково. Apple публікує стандартну, і ви можете послатися на неї; де розміщується кожен варіант, дивіться в посібнику про Terms of Use (EULA).

Для застосунку без підписок Apple умов теж не вимагає.

То чому вони є майже в кожному застосунку?

Бо «магазин цього не вимагає» і «вам це не потрібно» — різні твердження. Умови — це документ, який відповідає на запитання, яких не покриває жодна політика конфіденційності:

• Хто може користуватися застосунком і що буває, коли хтось ним зловживає. Без умов у вас немає заявленої підстави закрити обліковий запис.
• Що ви винні користувачеві, а що ні. Відмови від гарантій і обмеження відповідальності розміщуються тут, і саме через них умови взагалі існують.
• Що користувач винен вам — оплата, допустиме використання, контент, який він завантажує.
• Яке право застосовується і де розглядаються спори.
• Як змінюються умови і що буде, якщо якесь положення не має законної сили.

Якщо у вашому застосунку є облікові записи, він приймає гроші, розміщує контент користувачів або має хоч якусь модерацію, на ці запитання вам рано чи пізно знадобиться відповідь. Написати її до спору дешевше, ніж після.

Що має бути в умовах застосунку

Робочий набір розділів у тому порядку, в якому їх зазвичай найзручніше читати:

Розділ	Що він визначає
Використання застосунку	Ліцензія на використання, допустиме використання, за що закривають обліковий запис
Облікові записи	Хто може зареєструватися, ваше право призупинити обліковий запис, право користувача його видалити
Покупки й підписки	Оплата, поновлення, повернення коштів — і те, що платіж обробляє магазин, а не ви
Інтелектуальна власність	Кому належить застосунок, кому належить те, що завантажує користувач
Відмова від гарантій і обмеження відповідальності	Суть документа
Зміни	Як ви оновлюєте умови і як про це повідомляють користувачів
Контакти	Справжня адреса

Зверніть увагу, чого тут немає: обробки даних. Їй місце в політиці конфіденційності, а дублювання в двох документах — саме те, через що вони врешті суперечать один одному.

Чого уникати

• Копіювати умови іншого застосунку, замінивши назви. Це проблема з авторським правом, до того ж документ описує чужий бізнес.
• Обіцяти те, чого ви не можете виконати. Умови, які кажуть, що ви миттєво видаляєте всі дані або гарантуєте безперебійну роботу, гірші за мовчання.
• Обирати юрисдикцію навмання. Застосовне право — це реальний вибір із реальними наслідками.
• Ховати їх. Якщо до умов можна дістатися лише за посиланням, яке ви прибрали під час останнього редизайну, як захист вони мало чого варті.

Як написати їх з AI-асистентом

Асистент охоче напише умови, і типова помилка та сама, що й з політикою конфіденційності: на прохання «умови використання для мого застосунку» він пише усереднений варіант усіх умов, які прочитав, — арбітражні застереження, суд у штаті, де ви ніколи не були, обіцянки щодо безперебійної роботи. Промпт нижче тримає його в межах стандартних розділів вище, змушує перевірити, що насправді робить ваш застосунок (вхід, покупки, контент користувачів), перш ніж писати, і позначати те, чого він не знає, як [confirm: …], замість того щоб вигадувати. Якщо застосунок приймає платежі на iOS, він має містити посилання на стандартну EULA від Apple.

Копіюйте його повністю. Замініть факти в квадратних дужках угорі або залиште їх, і асистент запитає.

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.

Він написаний для сторінок, що публікуються на AppFoyer, тому просить заповнювачі на кшталт {{app_name}} і закінчується нашою відмовою від відповідальності. Якщо ви публікуєте деінде, видаліть ці рядки в Step 3 і попросіть натомість значення. Для політики конфіденційності дивіться Як написати політику конфіденційності з AI-асистентом.

Що тут робить AppFoyer

Умови — одна з п’яти сторінок, які ми генеруємо, поряд із політикою конфіденційності, сторінкою підтримки і сторінкою видалення облікового запису. Шаблон охоплює розділи вище, підставляє назву вашого застосунку, ім’я розробника, адресу підтримки і посилання на магазини та додає розділи про підписки — зокрема посилання на стандартну EULA від Apple, — коли ви вказуєте, що застосунок продає підписки на iOS.

Редактор умов у дашборді також має панель Write it with your own AI: промпт вище, уже заповнений даними вашого застосунку. Запустіть його в будь-якому асистенті, вставте відповідь назад, перегляньте попередній вигляд, опублікуйте.

Чеклист відповідності позначає сторінку, доки її не опубліковано, а для застосунку з підписками — доки посилання на EULA справді не з’явиться.

Як і кожна згенерована сторінка, це шаблон, який ви доповнюєте і за який відповідаєте, а не юридична порада. Якщо ваш застосунок має справу з грошима, даними про здоров’я або дітьми, дайте його прочитати юристові.

Авторитетні джерела

• Політика щодо даних користувачів (User Data policy) — довідка Google Play. Цитата вище взята з цієї сторінки.
• Правила перевірки App Store (App Store Review Guidelines) — Apple. Розділ 3.1.2 — це правило щодо підписок.
• Licensed Application End User License Agreement — стандартна EULA від Apple.