你的 App 需要服务条款吗？

网上有很多言之凿凿的文章，说两个商店都要求服务条款。去读一读商店自己的页面，就会发现它们并不是这么说的——所以值得把这个问题里藏着的三个不同问题分开来看。

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.”（译文：所有 App 都必须在 Play Console 的指定字段中发布隐私政策链接，并在 App 内提供隐私政策链接或文本。）隐私政策，两处。它完全没有提到服务条款，控制台里也没有对应的字段。

Play Console 的 App content（应用内容）部分会要求填写隐私政策 URL，如果你的 App 有账号，还要填写数据删除 URL。条款不在其中。

Apple 要求吗？

只在一种情况下要求，而且这种情况很常见：提供自动续期订阅的 App。审核指南 3.1.2 要求提供指向隐私政策和 Terms of Use (EULA) 的有效链接——在 App 内和元数据中都要有。

你不必自己写这份 EULA。Apple 发布了一份标准 EULA，你可以直接链接它；各版本分别放在哪里，请参阅 Terms of Use (EULA) 指南。

对于没有订阅的 App，Apple 也不要求条款。

那为什么几乎每个 App 都有条款？

因为”商店不要求”和”你不需要”是两回事。条款这份文档回答的是隐私政策不涉及的问题：

• 谁可以使用 App，以及有人滥用时会怎样。没有条款，你关闭账号就没有书面依据。
• 你对用户负有什么义务，以及不负有什么义务。免责声明和责任限制就写在这里，它们正是条款存在的理由。
• 用户对你负有什么义务——付款、可接受的使用方式、他们上传的内容。
• 适用哪国法律，以及争议在哪里审理。
• 条款如何变更，以及某个条款无法执行时怎么办。

如果你的 App 有账号、收钱、托管用户内容或者有任何形式的内容管理，这些问题你迟早需要答案。在纠纷发生之前写好，比之后再写成本低。

App 条款里应该有什么

一套可行的章节，按通常最易读的顺序排列：

章节	解决什么问题
App 的使用	使用许可、可接受的使用方式、什么行为会导致账号被关闭
账号	谁可以注册、你暂停账号的权利、用户删除账号的权利
购买和订阅	计费、续订、退款——以及付款由商店处理，而不是由你处理
知识产权	App 归谁所有，用户上传的内容归谁所有
免责声明和责任限制	这份文档的核心
变更	你如何更新条款，以及如何通知用户
联系方式	一个真实的地址

注意没有列出的内容：数据处理。那属于隐私政策，在两份文档里重复写同样的内容，正是两者最终互相矛盾的原因。

应该避免什么

• 照搬别的 App 的条款，只改个名字。 这在一份描述别人业务的文档之上，又多了一个版权问题。
• 承诺你做不到的事。 声称会立即删除所有数据或保证正常运行时间的条款，比什么都不写更糟。
• 随便指定一个司法管辖区。 适用法律是一个真正的选择，有真正的后果。
• 把条款藏起来。 如果只能通过一个在上次改版中被你删掉的链接访问条款，那它作为抗辩依据就没多大用处。

用 AI 助手来写

AI 助手很乐意帮你写条款，而常见的问题和写隐私政策时一样：让它写”我的 App 的服务条款”，它就会写出它读过的所有条款的平均版本——仲裁条款、某个你从未去过的州的法院、关于正常运行时间的承诺。下面的提示词把它限制在上面那些标准章节内，让它在动笔前先核实你的 App 实际做了什么（登录、购买、用户内容），并对不知道的内容标记 [confirm: …]，而不是凭空编造。如果 App 在 iOS 上收款，就必须包含 Apple 标准 EULA 的链接。

请完整复制。替换顶部方括号中的事实，或者保留它们，让助手来问你。

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}} 这类占位符，并以我们的免责声明结尾。如果你在其他地方发布，请删除第 3 步中的这些行，改为让助手询问具体的值。隐私政策请参阅用 AI 助手写隐私政策。

AppFoyer 在这里做什么

条款是我们生成的五个页面之一，另外几个是隐私政策、支持页面和账号删除页面。模板涵盖上述章节，填入你的 App 名称、开发者名称、支持邮箱和商店链接，并在你说明 App 在 iOS 上销售订阅时加入订阅相关章节——包括 Apple 标准 EULA 的链接。

控制面板里的条款编辑器还有一个 Write it with your own AI（用你自己的 AI 来写）面板：就是上面的提示词，已经填好了你的 App 信息。在任意助手中运行它，把回复粘贴回来，查看预览，然后发布。

合规检查清单会一直标记这个页面，直到它发布为止；对于订阅类 App，还要直到 EULA 链接确实存在为止。

和每个生成的页面一样，它是一份由你补充完成并由你负责的模板，不是法律建议。如果你的 App 涉及金钱、健康数据或儿童，请让律师审阅。

权威来源

• User Data 政策 — Google Play 帮助。上面的引文出自此页。
• App Store 审核指南 — Apple。第 3.1.2 节是订阅规则。
• Licensed Application End User License Agreement — Apple 的标准 EULA。