Нужны ли вашему приложению условия использования?

В интернете много уверенных текстов о том, что оба магазина требуют условия использования. Если прочитать собственные страницы магазинов, там сказано не это, — поэтому стоит разделить три разных вопроса, которые прячутся в этом одном.

Требует ли их Google Play?

Нет. Политика Play User Data конкретно указывает, что и где должно быть по ссылке: “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?

Только в одном случае, причём распространённом: приложения с автопродлеваемыми подписками. Guideline 3.1.2 требует работающих ссылок и на политику конфиденциальности, и на Terms of Use (EULA) — в самом приложении и в метаданных.

Писать это EULA самостоятельно не обязательно. Apple публикует стандартное, и вместо своего можно дать ссылку на него; где размещается каждый вариант, смотрите в руководстве по Terms of Use (EULA).

Для приложения без подписок Apple условий тоже не требует.

Так почему они есть почти у каждого приложения?

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

• Кто может пользоваться приложением и что происходит при злоупотреблении. Без условий у вас нет заявленного основания закрыть аккаунт.
• Что вы должны пользователю, а что нет. Здесь живут отказ от гарантий и ограничение ответственности, и именно ради них условия вообще существуют.
• Что пользователь должен вам — оплата, допустимое использование, загружаемый им контент.
• Какое право применяется и где рассматриваются споры.
• Как меняются условия и что происходит, если какой-то пункт не имеет юридической силы.

Если в вашем приложении есть аккаунты, оно принимает деньги, размещает пользовательский контент или есть хоть какая-то модерация, на эти вопросы рано или поздно понадобится ответ. Написать его до спора дешевле, чем после.

Что должно быть в условиях приложения

Рабочий набор разделов в том порядке, в котором их обычно удобнее всего читать:

Раздел	Что он определяет
Использование приложения	Лицензия на использование, допустимое использование, за что закрывают аккаунт
Аккаунты	Кто может регистрироваться, ваше право приостановить аккаунт, право пользователя удалить его
Покупки и подписки	Оплата, продление, возвраты — и то, что платёж обрабатывает магазин, а не вы
Интеллектуальная собственность	Кому принадлежит приложение, кому принадлежит то, что загружает пользователь
Отказ от гарантий и ограничение ответственности	Ядро документа
Изменения	Как вы обновляете условия и как об этом узнают пользователи
Контакты	Реальный адрес

Обратите внимание, чего здесь нет: обработки данных. Ей место в политике конфиденциальности, а если дублировать её в двух документах, они в итоге начнут противоречить друг другу.

Чего избегать

• Копировать условия другого приложения, поменяв названия. Это проблема с авторским правом вдобавок к документу, который описывает чужой бизнес.
• Обещать то, чего вы не можете. Условия, где сказано, что вы мгновенно удаляете все данные или гарантируете uptime, хуже, чем молчание.
• Выбирать юрисдикцию наугад. Применимое право — это реальный выбор с реальными последствиями.
• Прятать их. Если до условий можно добраться только по ссылке, которую вы убрали при последнем редизайне, в качестве защиты от них мало толку.

Как написать их с помощью AI-ассистента

Ассистент охотно напишет условия, и типичный сбой тот же, что и с политикой конфиденциальности: на просьбу «условия использования для моего приложения» он пишет усреднение всех условий, которые читал, — арбитражные оговорки, суд в штате, где вы никогда не были, обещания про uptime. Промпт ниже удерживает его в рамках стандартных разделов выше, заставляет перед написанием проверить, что приложение делает на самом деле (вход, покупки, пользовательский контент), и отмечать то, чего он не знает, через [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, поэтому запрашивает placeholders вида {{app_name}} и заканчивается нашим дисклеймером. Если вы публикуете в другом месте, удалите эти строки в Step 3 и попросите вместо них сами значения. О политике конфиденциальности см. Как написать политику конфиденциальности с помощью AI-ассистента.

Что здесь делает AppFoyer

Условия — одна из пяти страниц, которые мы генерируем, наряду с политикой конфиденциальности, страницей поддержки и страницей удаления аккаунта. Шаблон охватывает разделы выше, подставляет название приложения, имя разработчика, адрес поддержки и ссылки на магазины, а также добавляет разделы о подписках — включая ссылку на стандартное EULA Apple, — если вы укажете, что приложение продаёт подписки на iOS.

В редакторе условий в дашборде также есть панель Write it with your own AI: промпт выше, уже заполненный данными вашего приложения. Запустите его в любом ассистенте, вставьте ответ обратно, прочитайте предпросмотр, опубликуйте.

Чек-лист соответствия продолжает отмечать страницу, пока она не опубликована, а для приложения с подписками — пока ссылка на EULA действительно не появится.

Как и любая сгенерированная страница, это шаблон, который вы дополняете и за который отвечаете, а не юридическая консультация. Если ваше приложение связано с деньгами, данными о здоровье или детьми, дайте его прочитать юристу.

Официальные источники

• Политика User Data — Справка Google Play. Цитата выше взята с этой страницы.
• App Store Review Guidelines — Apple. Раздел 3.1.2 — правило о подписках.
• Licensed Application End User License Agreement — стандартное EULA Apple.