¿Tu app necesita términos de servicio?

Hay mucho texto en internet que afirma con seguridad que ambas tiendas exigen términos de servicio. Si lees las páginas de las propias tiendas, no es eso lo que dicen, así que conviene separar las tres preguntas distintas que se esconden dentro de esta.

¿Lo exige Google Play?

No. La política User Data de Play es concreta sobre qué hay que enlazar y dónde: “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.” (Traducción: «Todas las apps deben publicar un enlace a la política de privacidad en el campo designado de Play Console, y un enlace o el texto de la política de privacidad dentro de la propia app».) Una política de privacidad, dos veces. No dice nada sobre términos de servicio, y no hay ningún campo en la consola para ellos.

La sección App content (Contenido de la app) de Play Console pide la URL de la política de privacidad y, si tu app tiene cuentas, una URL de eliminación de datos. Los términos no están entre ellas.

¿Lo exige Apple?

Solo en un caso, y es un caso frecuente: apps que ofrecen suscripciones con renovación automática. La directriz 3.1.2 exige enlaces funcionales tanto a la política de privacidad como a unos Terms of Use (EULA), dentro de la app y en los metadatos.

No tienes que redactar ese EULA. Apple publica uno estándar y puedes enlazarlo en su lugar; consulta la guía de Terms of Use (EULA) para saber dónde va cada versión.

Para una app sin suscripciones, Apple tampoco exige términos.

Entonces, ¿por qué casi todas las apps los tienen?

Porque «no lo exige una tienda» y «no los necesitas» son afirmaciones distintas. Los términos son el documento que responde a preguntas que ninguna política de privacidad cubre:

• Quién puede usar la app y qué pasa cuando alguien abusa de ella. Sin términos no tienes una base declarada para cerrar una cuenta.
• Qué le debes al usuario y qué no. Las exclusiones de garantía y los límites de responsabilidad van aquí, y son la razón de que existan los términos.
• Qué te debe el usuario a ti: pago, uso aceptable, el contenido que sube.
• Qué ley se aplica y dónde se resuelven las disputas.
• Cómo cambian los términos y qué pasa si una cláusula no es exigible.

Si tu app tiene cuentas, cobra dinero, aloja contenido de usuarios o tiene cualquier tipo de moderación, son preguntas a las que tarde o temprano tendrás que responder. Escribirlo antes de la disputa es más barato que después.

Qué va en los términos de una app

Un conjunto práctico de secciones, en el orden en que suelen leerse mejor:

Sección	Qué resuelve
Uso de la app	Licencia de uso, uso aceptable, qué hace que se cierre una cuenta
Cuentas	Quién puede registrarse, tu derecho a suspender, el derecho del usuario a eliminar
Compras y suscripciones	Facturación, renovación, reembolsos, y que el pago lo procesa la tienda, no tú
Propiedad intelectual	De quién es la app, de quién es lo que sube el usuario
Exclusión y limitación de responsabilidad	El núcleo del documento
Cambios	Cómo actualizas los términos y cómo se avisa a los usuarios
Contacto	Una dirección real

Fíjate en lo que no está: el tratamiento de datos. Eso pertenece a la política de privacidad, y duplicarlo en dos documentos es la forma en que acaban contradiciéndose.

Qué evitar

• Copiar los términos de otra app cambiando los nombres. Es un problema de derechos de autor, además de un documento que describe el negocio de otra persona.
• Prometer lo que no puedes cumplir. Unos términos que dicen que borras todos los datos al instante, o que garantizan disponibilidad, son peores que el silencio.
• Elegir una jurisdicción al azar. La ley aplicable es una elección real con consecuencias reales.
• Esconderlos. Si solo se puede llegar a los términos desde un enlace que quitaste en el último rediseño, no sirven de mucho como defensa.

Escribirlos con un asistente de IA

Un asistente escribirá términos encantado, y el fallo habitual es el mismo que con una política de privacidad: si le pides «términos de servicio para mi app», escribe el promedio de todos los términos que ha leído —cláusulas de arbitraje, un tribunal en un estado donde nunca has estado, promesas de disponibilidad—. El prompt de abajo lo limita a las secciones estándar anteriores, le hace comprobar qué hace realmente tu app (inicio de sesión, compras, contenido de usuarios) antes de escribir, y le pide marcar lo que no sabe con [confirm: …] en vez de inventarlo. Si la app cobra pagos en iOS, debe incluir el enlace al EULA estándar de Apple.

Cópialo entero. Sustituye los datos entre corchetes del principio, o déjalos y deja que el asistente pregunte.

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.

Está escrito para páginas publicadas en AppFoyer, y por eso pide marcadores del estilo {{app_name}} y termina con nuestro aviso legal. Si publicas en otro sitio, borra esas líneas del Step 3 y pide los valores en su lugar. Para la política de privacidad, consulta Escribir tu política de privacidad con un asistente de IA.

Qué hace AppFoyer aquí

Los términos son una de las cinco páginas que generamos, junto con la política de privacidad, la de soporte y la de eliminación de cuenta. La plantilla cubre las secciones anteriores, rellena el nombre de tu app, el nombre del desarrollador, la dirección de soporte y los enlaces a las tiendas, y añade las secciones de suscripción —incluido el enlace al EULA estándar de Apple— cuando le indicas que la app vende suscripciones en iOS.

El editor de términos del panel también tiene un apartado Write it with your own AI: el prompt de arriba, ya rellenado con los datos de tu app. Ejecútalo en cualquier asistente, pega la respuesta, revisa la vista previa y publica.

La checklist de cumplimiento mantiene la página marcada hasta que se publica y, en una app de suscripción, hasta que el enlace al EULA está realmente ahí.

Como toda página generada, es una plantilla que tú completas y de la que eres responsable, no asesoramiento legal. Si tu app maneja dinero, datos de salud o menores, haz que la lea un abogado.

Las fuentes oficiales

• User Data policy — Ayuda de Google Play. La cita de arriba es de esta página.
• App Store Review Guidelines — Apple. La sección 3.1.2 es la norma sobre suscripciones.
• Licensed Application End User License Agreement — el EULA estándar de Apple.