O seu app precisa de termos de serviço?

Há muitos textos confiantes na internet dizendo que as duas lojas exigem termos de serviço. Leia as páginas das próprias lojas e não é isso que elas dizem — por isso vale separar as três perguntas diferentes escondidas dentro desta.

O Google Play exige?

Não. A política de Dados do usuário do Play é específica sobre o que precisa ter link e onde: “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.” (Tradução: “Todos os apps devem publicar um link para a política de privacidade no campo designado do Play Console, e um link ou o texto da política de privacidade dentro do próprio app.”) Uma política de privacidade, duas vezes. Não diz nada sobre termos de serviço, e não há nenhum campo no console para eles.

A seção App content (Conteúdo do app) do Play Console pede uma URL de política de privacidade e, se o seu app tem contas, uma URL de exclusão de dados. Termos não estão entre elas.

A Apple exige?

Só em um caso, e é um caso comum: apps que oferecem assinaturas com renovação automática. A diretriz 3.1.2 exige links funcionais tanto para a política de privacidade quanto para os Terms of Use (EULA) — no próprio app e nos metadados.

Você não precisa escrever esse EULA. A Apple publica um padrão e você pode colocar o link dele no lugar; veja o guia de Terms of Use (EULA) para saber onde vai cada versão.

Para um app sem assinaturas, a Apple também não exige termos.

Então por que quase todo app os tem?

Porque “não é exigido por uma loja” e “você não precisa deles” são afirmações diferentes. Os termos são o documento que responde perguntas que nenhuma política de privacidade cobre:

• Quem pode usar o app, e o que acontece quando alguém abusa dele. Sem termos, você não tem uma base declarada para encerrar uma conta.
• O que você deve ao usuário, e o que não deve. Isenções de garantia e limites de responsabilidade ficam aqui, e são a razão de os termos existirem.
• O que o usuário deve a você — pagamento, uso aceitável, o conteúdo que ele envia.
• Qual lei se aplica e onde as disputas são julgadas.
• Como os termos mudam, e o que acontece se uma cláusula não puder ser aplicada.

Se o seu app tem contas, recebe dinheiro, hospeda conteúdo de usuários ou tem qualquer moderação, essas são perguntas que você vai precisar responder um dia. Escrever antes da disputa sai mais barato do que depois.

O que entra nos termos de um app

Um conjunto de seções que funciona, na ordem em que costumam ser lidas melhor:

Seção	O que ela resolve
Uso do app	Licença de uso, uso aceitável, o que leva ao encerramento de uma conta
Contas	Quem pode se cadastrar, o seu direito de suspender, o direito do usuário de excluir
Compras e assinaturas	Cobrança, renovação, reembolsos — e que a loja, não você, processa o pagamento
Propriedade intelectual	Quem é dono do app, quem é dono do que o usuário envia
Isenção e limitação de responsabilidade	O núcleo do documento
Alterações	Como você atualiza os termos e como os usuários são avisados
Contato	Um endereço real

Repare no que não está ali: o tratamento de dados. Isso pertence à política de privacidade, e duplicá-lo em dois documentos é o caminho para que os dois acabem se contradizendo.

O que evitar

• Copiar os termos de outro app trocando os nomes. É um problema de direitos autorais, além de um documento que descreve o negócio de outra pessoa.
• Prometer o que você não pode cumprir. Termos que dizem que você exclui todos os dados instantaneamente, ou que garantem disponibilidade, são piores que o silêncio.
• Escolher uma jurisdição ao acaso. A lei aplicável é uma escolha real com consequências reais.
• Escondê-los. Se os termos só podem ser acessados por um link que você removeu no último redesign, eles não servem muito como defesa.

Como escrevê-los com um assistente de IA

Um assistente escreve termos de bom grado, e a falha habitual é a mesma que acontece com uma política de privacidade: quando você pede “termos de serviço para o meu app”, ele escreve a média de todos os termos que já leu — cláusulas de arbitragem, um tribunal em um estado onde você nunca esteve, promessas de disponibilidade. O prompt abaixo o limita às seções padrão acima, faz com que ele verifique o que o seu app realmente faz (login, compras, conteúdo de usuários) antes de escrever, e faz com que ele marque o que não sabe com [confirm: …] em vez de inventar. Se o app recebe pagamentos no iOS, ele precisa incluir o link do EULA padrão da Apple.

Copie inteiro. Substitua os dados entre colchetes no início, ou deixe-os e deixe o assistente perguntar.

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.

Ele foi escrito para páginas publicadas no AppFoyer, e é por isso que pede placeholders no estilo {{app_name}} e termina com o nosso aviso legal. Se você publicar em outro lugar, apague essas linhas no Step 3 e peça os valores no lugar. Para a política de privacidade, veja Como escrever a sua política de privacidade com um assistente de IA.

O que o AppFoyer faz aqui

Os termos são uma das cinco páginas que geramos, junto com a política de privacidade, a página de suporte e a de exclusão de conta. O modelo cobre as seções acima, preenche o nome do app, o nome do desenvolvedor, o endereço de suporte e os links das lojas, e acrescenta as seções de assinatura — incluindo o link do EULA padrão da Apple — quando você informa que o app vende assinaturas no iOS.

O editor de termos no painel também tem um painel Write it with your own AI (Escreva com a sua própria IA): o prompt acima, já preenchido com os dados do seu app. Rode-o em qualquer assistente, cole a resposta de volta, leia a pré-visualização e publique.

O checklist de conformidade mantém a página sinalizada até que ela seja publicada e, para um app com assinaturas, até que o link do EULA esteja de fato lá.

Como toda página gerada, é um modelo que você completa e pelo qual é responsável, não aconselhamento jurídico. Se o seu app lida com dinheiro, dados de saúde ou crianças, peça a um advogado que o leia.

As fontes oficiais

• User Data policy — Ajuda do Google Play. A citação acima é desta página.
• App Store Review Guidelines — Apple. A seção 3.1.2 é a regra das assinaturas.
• Licensed Application End User License Agreement — o EULA padrão da Apple.