Prepara una app para las tiendas desde tu agente de programación

Tu agente lee la app que tiene delante —SDK, permisos, bundle id— y redacta cada página de cumplimiento a partir de lo que encuentra. Tú lees los borradores y los publicas. El agente no puede.

Antes de empezar

Necesitas Claude Code y una cuenta de AppFoyer. El plan gratuito basta: crea una. No hay que crear ninguna clave: la primera vez que se conecta, el agente te pide que lo apruebes en el navegador.

¿No usas ningún agente de programación? Seis campos en el navegador te dan las mismas cinco páginas sin el plugin.

¿No usas Claude Code? El plugin lo necesita, pero las páginas de privacidad y de términos no: sus editores en el panel tienen un prompt, rellenado con los datos de tu app, que ejecutas en cualquier asistente y cuya respuesta pegas de vuelta. Está completo en la guía de la política de privacidad y en la guía de los términos.

Instalación

claude
/plugin marketplace add appfoyer/claude-plugin
/plugin install appfoyer@appfoyer

No necesitas cuenta para empezar: el agente lee tu build, te muestra lo que ha encontrado y te hace sus preguntas en tu máquina, y solo te pide que te conectes cuando hay algo que guardar. La primera vez que llama a AppFoyer, tu navegador se abre en una página de aprobación: inicia sesión o crea una cuenta gratuita, comprueba el nombre y a dónde vuelve el navegador, y aprueba. Claude Code conserva la conexión y la renueva por sí solo; no se copia nada ni se guarda nada en tu shell. Si el navegador no se abre, ejecuta /mcp, elige appfoyer y selecciona Authenticate. En la app de escritorio de Claude Code, conéctate una vez de esta forma desde un terminal y luego inicia ahí una sesión nueva: una sesión que ya estaba abierta no ve la nueva conexión. Desconéctala en la página Agent del panel y la siguiente llamada falla de inmediato. Claude Code no actualiza por sí solo un marketplace de terceros: en /plugin → Marketplaces → appfoyer, elige Enable auto-update para recibir las nuevas versiones.

¿No hay navegador en esa máquina? ¿Un servidor remoto, un contenedor, una ejecución automatizada? Usa una API key: créala en Agent → API key — for CI and headless use, instala el plugin como arriba para tener el flujo de trabajo y añade el servidor una vez más con la clave en su cabecera:

export APPFOYER_API_KEY=cpk_…
claude mcp add --transport http appfoyer-key https://app.appfoyer.com/mcp --header "Authorization: Bearer $APPFOYER_API_KEY"

El plugin lee la clave solo de esa variable de entorno: el skill nunca la ve, y solo viaja en la cabecera Authorization que rellena Claude Code.

Otro cliente MCP —claude.ai, Claude Desktop, Cursor, VS Code— puede conectarse a https://app.appfoyer.com/mcp de la misma forma, con la misma página de aprobación. Obtiene las herramientas; el flujo de trabajo paso a paso que lee tus archivos de build viene con el plugin de Claude Code.

Qué decir

Ejecuta esto dentro del repositorio de tu app, no en un directorio vacío:

Di	Qué pasa
`Make this app store-ready`	Analiza los archivos de build, confirma los datos que no pudo deducir, redacta cada página y devuelve un enlace de revisión.
`Is this app store-ready?`	Auditoría de solo lectura con la lista de comprobación de cumplimiento. No escribe nada.
`Wire the store-ready links into the app`	Después de publicar: propone los enlaces de privacidad y soporte dentro de la app como un diff que revisas tú.
`Add the AppFoyer drift check`	Propone un workflow de GitHub que señala los pull requests que añaden un SDK o un permiso que las páginas quizá no cubran. Cómo funciona.

Ejemplos

Dilo con tus propias palabras; estos son los casos que gestiona el skill.

Una app, primera ejecución

> Make this app store-ready

Enumera lo que ha encontrado en los archivos de build —SDK, permisos, bundle id—, cada cosa con su archivo y su línea.
Solo pregunta lo que no pudo encontrar: nombre de la empresa, email de soporte, jurisdicción, enlaces de las tiendas. Como mucho, dos rondas.
Crea la app, sube el icono desde el repositorio y redacta las cinco páginas.
Termina con un enlace de revisión. Nada es público hasta que publicas ahí.

Volver a ejecutarlo tras un cambio

> Make this app store-ready

Encuentra la app existente por su application id y compara los datos nuevos con los guardados.
Vuelve a redactar solo las páginas a las que afecta el cambio, como la de privacidad tras un SDK de analíticas nuevo.
No toca el icono ni la dirección salvo que se lo pidas.

Varios flavors, nombrados en el prompt

> Make com.acme.weather.free and com.acme.weather.pro store-ready

Crea dos apps y no pregunta nada sobre la selección.
Lee la carpeta, el nombre y las dependencias propios de cada flavor. Un SDK de anuncios que solo usa el flavor free no se incluye en la política de privacidad del flavor pro.
Devuelve un enlace de revisión y una tabla de URLs de consola para cada flavor.

Varios flavors, sin nombrar

> Make this app store-ready

Enumera los flavors con sus application ids, todos preseleccionados, y tú eliges cuáles tienen sitio.
Los build types como debug y staging aparecen como excluidos, no se ofrecen.

Dimensiones marca × entorno

> Make every brand store-ready

Enumera combinaciones (brandAProd, brandBProd), no flavors sueltos.
Solo ofrece el entorno de producción. dev y qa nunca llegan a una tienda.
Lee el nombre de la app de Gradle (resValue, manifestPlaceholders) o de source sets movidos cuando la build lo pone ahí.
Si no puede saber si una dimensión son entornos o marcas, pregunta.

Dirección personalizada (Pro y Advanced)

> Make this app store-ready

Crea la dirección a partir del nombre de la app en inglés, por ejemplo weather-now.
Si está ocupada o se parece demasiado a un nombre de marca, prueba la siguiente —weather-now-app, acme-weather—, como mucho cinco veces, y luego te pregunta.
En el plan gratuito mantiene la dirección app-… y te indica que la personalizada viene con Pro.
La dirección app-… sigue sirviendo el mismo sitio.

Cambiar una dirección que ya usas

> Change the address to weather-radar

Primero pregunta. La dirección personalizada anterior se libera de inmediato, y una ficha de la tienda que aún la nombre deja de funcionar.
Solo la cambia después de que digas que sí.

Actualizar el icono

> Update the app icon

Encuentra el icono del launcher: el icono de 512 de Play, la imagen mipmap más grande o la imagen de marketing del AppIcon de iOS, empezando por la del propio flavor.
Si supera los 512 KB, reduce una copia en una carpeta temporal. Tu repositorio no se toca.
Te dice qué archivo ha subido. En una app publicada, el icono nuevo está en línea de inmediato.

Una app con anuncios

> Make this app store-ready. AdMob publisher id pub-0000000000000000

Escribe app-ads.txt a partir de las líneas que le das. El publisher id no está en tu código, así que nunca se lo inventa.
Te recuerda que pongas el sitio como sitio web del desarrollador en la ficha de la tienda.
AdMob ha verificado archivos app-ads.txt en nuestras direcciones; espera hasta 24 horas a que lo rastree.

Mantener las páginas sincronizadas con la build

> Add the AppFoyer drift check

Cada ejecución de “make this app store-ready” escribe appfoyer.json en la raíz del repositorio: los SDK, tipos de datos y permisos a partir de los que se escribieron las páginas. Lo escribe el mismo escáner que ejecuta la comprobación, nunca a mano.
Este prompt muestra un workflow de GitHub para la appfoyer/check-action gratuita y escribe .github/workflows/appfoyer.yml cuando dices que sí. Nunca sobrescribe uno que ya tengas.
A partir de ahí, cada pull request enumera lo que añadió o quitó desde que se escribieron las páginas, con archivo y línea. Al ejecutar de nuevo el plugin se actualizan los borradores y appfoyer.json.
No se hace ningún commit por ti. La guía sobre cómo mantener sincronizada tu política de privacidad tiene los detalles y la configuración para otros sistemas de CI.

Comprobar sin cambiar nada

> Is this app store-ready?

Ejecuta la lista de comprobación para cada app que coincida e informa de lo que falta. No escribe nada.
Un flavor que aún no tiene app se indica como ausente.

Poner los enlaces dentro de la app

> Wire the store-ready links into the app

Necesita páginas publicadas.
Propone un diff para los enlaces de privacidad y soporte en tu pantalla de ajustes o en tus strings. Solo lo aplica cuando dices que sí, y nunca hace commit.

Qué sale de tu máquina

Solo datos deducidos:

el nombre, la plataforma y el bundle id o application id de la app;
los nombres de los SDK y permisos encontrados en tus archivos de build;
las respuestas que confirmas: nombre de la empresa, email de soporte, jurisdicción, URLs de las tiendas;
el texto de las páginas que redacta el agente, que se guarda en tu cuenta como borrador;
el propio icono de la app, enviado una sola vez mediante un enlace de subida de un solo uso.

Ningún otro archivo, nunca código fuente, nunca secretos ni claves encontrados en el repositorio. Lo que envía el agente es lo que una política de privacidad tiene que declarar de todos modos.

Se escribe un archivo dentro de tu repositorio y se queda ahí: appfoyer.json, el registro de a partir de qué se escribieron las páginas, creado por el escáner incluido en el plugin. No se envía a ningún sitio. El agente nunca hace commit de él ni de nada más: eso lo haces tú.

Lo que el agente no puede hacer

Tanto si se conecta a través del navegador como con una API key, el plugin tiene una credencial de agente, así que publicar no está a su alcance en absoluto. Esto se aplica en el servidor, no pidiéndole amablemente al agente:

No hay herramienta de publicación. El agente escribe borradores; tus páginas publicadas no cambian.
Dos cosas no tienen borrador: el icono y la dirección personalizada. En una app publicada cambian el sitio en línea de inmediato, y el agente te avisa cuando las ha cambiado. No puede sustituir una dirección personalizada que ya usas sin tu sí.
La ruta REST que publica una página rechaza directamente las credenciales de agente: solo sesión.
Cada página sigue pasando por la misma revisión de contenido al publicar que una edición hecha a mano.
Cada llamada del agente queda registrada en el registro de auditoría de la cuenta con la conexión o la clave que la hizo.

Así que lo peor que puede pasar con una conexión o una clave comprometida son borradores que descartar, un icono equivocado o una dirección nueva, no una página que se hace pública en tu nombre.

Las herramientas que recibe

El plugin se conecta a un endpoint MCP que expone exactamente estas:

Herramienta		Qué hace
`list_apps`	Lectura	Cada app de la cuenta con su slug, su URL pública y si tiene algo publicado.
`get_app`	Lectura	Una app: configuración, datos guardados sobre la recopilación de datos y, de cada página, el texto publicado, el estado de publicación y el borrador pendiente.
`create_app`	Escritura	Crea una app con páginas de plantilla. Nada es público.
`create_apps`	Escritura	Crea hasta diez apps en una sola llamada, una por product flavor. Cada una empieza sin publicar.
`update_app`	Escritura	Cambia la configuración, los datos guardados sobre la recopilación de datos o la lista de SDK. Nunca edita el texto de las páginas.
`set_page`	Escritura	Escribe el borrador de una página. La página publicada no se toca.
`set_ad_lines`	Escritura	Sustituye app-ads.txt. Solo se usa cuando hay un SDK de anuncios y has proporcionado los publisher ids.
`get_checklist`	Lectura	La lista de comprobación para las tiendas calculada en el servidor, más qué páginas tienen aún borradores sin publicar.
`get_store_forms`	Lectura	Borradores de respuestas para el formulario Data safety de Google Play y los detalles de App Privacy de Apple, a partir de los datos y la lista de SDK. Las introduces tú en la consola.
`request_publish`	Escritura	Indica que la redacción ha terminado y devuelve la URL de revisión. No publica nada.
`set_icon`	Escritura	Devuelve una URL de subida de un solo uso para el icono de la app. Está en línea de inmediato: un icono no tiene borrador.
`check_slug`	Lectura	Comprueba una dirección personalizada (Pro y Advanced) con las mismas reglas que el panel.
`set_slug`	Escritura	Reclama una dirección personalizada. Está en línea de inmediato. Se niega a sustituir una que ya tienes salvo que hayas dado tu acuerdo.

Cuando algo sale mal

Síntoma	Causa
Las herramientas muestran "needs authentication"	La conexión nunca se aprobó o se desconectó. Ejecuta `/mcp`, elige appfoyer y selecciona Authenticate.
La página de aprobación dice que la solicitud no se puede usar	El enlace caducó o se abrió dos veces. Vuelve a empezar desde el editor; no se conectó nada.
`unauthorized` con una API key	La clave se revocó en el panel o pertenece a otra cuenta. Crea una nueva y vuelve a exportarla.
Publicar devuelve un error de cuota	Se ha agotado el límite de apps publicadas del plan. La app y sus borradores se conservan: despublica otra app o mejora tu plan, y luego publica desde la pantalla de revisión.
Un borrador vuelve rechazado o retenido	La revisión de contenido detectó algo. Los motivos indican qué coincidió y cómo corregirlo; edita y vuelve a enviar. No cambió nada público.

Una cosa que esto no cambia

Los borradores son plantillas completadas a partir de tu código, no asesoramiento legal. Que un agente los escriba rápido no los hace ciertos: lee lo que ha escrito antes de publicar, sobre todo la lista de lo que recopila tu app. Eres tú a quien la tienda considera responsable.

Preguntas: support@appfoyer.com.