你的應用程式需要服務條款嗎？

網路上有很多語氣篤定的文章說，兩家商店都要求服務條款。但讀一讀商店自己的頁面，它們並不是這麼說的。所以值得把藏在這個問題裡的三個不同問題分開來看。

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 的指定欄位中張貼隱私權政策連結，並在應用程式本身中提供隱私權政策連結或文字。）兩次都是隱私權政策。它對服務條款隻字未提，主控台中也沒有對應的欄位。

Play Console 的 App content（應用程式內容）部分會要求隱私權政策網址，以及（如果你的應用程式有帳戶）資料刪除網址。條款不在其中。

Apple 要求嗎？

只有一種情況要求，而且這種情況很常見：提供自動續訂訂閱的應用程式。準則3.1.2 要求提供可正常運作的隱私權政策連結和 Terms of Use (EULA) 連結，應用程式內和中繼資料中都要有。

你不必自己撰寫那份 EULA。Apple 發布了一份標準 EULA，你可以改為連結它；各個版本該放在哪裡，請參閱Terms of Use (EULA) 指南。

對於沒有訂閱的應用程式，Apple 也不要求條款。

那為什麼幾乎每個應用程式都有條款？

因為「商店不要求」和「你不需要」是兩種不同的說法。條款這份文件回答的，是隱私權政策不涵蓋的問題：

• 誰可以使用這個應用程式，以及有人濫用時會怎樣。沒有條款，你就沒有明文依據可以關閉帳戶。
• 你對使用者負有什麼義務，以及不負有什麼義務。免責聲明和責任限制就寫在這裡，而這正是條款存在的理由。
• 使用者對你負有什麼義務：付款、可接受的使用方式、他們上傳的內容。
• 適用哪個法律，以及爭議在哪裡審理。
• 條款如何變更，以及某個條款無法執行時會怎樣。

如果你的應用程式有帳戶、會收款、存放使用者內容，或有任何形式的內容審核，這些問題你遲早都需要答案。在爭議發生前寫好，比之後再寫便宜。

應用程式的條款應該包含什麼

一組可行的章節，依照通常最好讀的順序：

章節	規範什麼
應用程式的使用	使用授權、可接受的使用方式、哪些行為會導致帳戶被關閉
帳戶	誰可以註冊、你停權的權利、使用者刪除帳戶的權利
購買與訂閱	計費、續訂、退款，以及處理付款的是商店而不是你
智慧財產權	應用程式歸誰所有、使用者上傳的內容歸誰所有
免責聲明與責任限制	這份文件的核心
變更	你如何更新條款、如何通知使用者
聯絡方式	一個真實的地址

注意這裡沒有什麼：資料處理。那屬於隱私權政策，把它在兩份文件裡重複寫一遍，正是兩者最後互相矛盾的原因。

應該避免的事

• 複製別的應用程式的條款，只改名稱。除了文件描述的是別人的業務之外，還有著作權問題。
• 承諾你做不到的事。條款寫著你會立即刪除所有資料，或保證正常運作時間，比什麼都不寫更糟。
• 隨便指定一個司法管轄區。準據法是一個真實的選擇，會帶來真實的後果。
• 把條款藏起來。如果條款只能從一個你在上次改版時拿掉的連結進入，那它作為防禦依據就沒什麼用。

用 AI 助理撰寫條款

AI 助理很樂意替你寫條款，而常見的失敗和隱私權政策一樣：你要它寫「我的應用程式的服務條款」，它就寫出它讀過的所有條款的平均值：仲裁條款、一個你從沒去過的州的法院、關於正常運作時間的承諾。下面的提示詞讓它只寫上述的標準章節，要它在動筆前先確認你的應用程式實際做了什麼（登入、購買、使用者內容），並讓它用 [confirm: …] 標出它不知道的部分，而不是自己編造。如果應用程式在 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}} 這類預留位置，並以我們的免責聲明結尾。如果你要發布在其他地方，請刪除 Step 3 中的那幾行，改為要求填入實際的值。隱私權政策的部分，請參閱用 AI 助理撰寫你的隱私權政策。

AppFoyer 在這裡做什麼

條款是我們產生的五個頁面之一，另外還有隱私權政策、支援頁面和帳戶刪除頁面。範本涵蓋上述章節，會填入你的應用程式名稱、開發者名稱、支援地址和商店連結；當你告訴它應用程式在 iOS 上販售訂閱時，還會加入訂閱相關章節，包括 Apple 標準 EULA 的連結。

儀表板中的條款編輯器還有一個 Write it with your own AI（用你自己的 AI 撰寫）面板：就是上面那段提示詞，已經填好你的應用程式資訊。在任何助理中執行它，把回覆貼回來，看過預覽，然後發布。

在頁面發布之前，合規檢查清單會一直標示這個頁面；對於訂閱型應用程式，則會一直標示到 EULA 連結確實出現為止。

和每個產生的頁面一樣，這是一份由你補完並由你負責的範本，不是法律建議。如果你的應用程式涉及金錢、健康資料或兒童，請找律師看過。

權威來源

• User Data 政策 — Google Play 說明。上面的引文出自這個頁面。
• App Store 審查準則 — Apple。第 3.1.2 節是訂閱規則。
• Licensed Application End User License Agreement（授權應用程式終端使用者授權協議）— Apple 的標準 EULA。