Cómo funciona el agente de envíos: del repositorio a la revisión de la tienda

Publicar es la parte del desarrollo de apps que casi todo el mundo pospone. El build está hecho, y lo que queda es el bundle ID, la pregunta sobre cifrado de exportación, el cuestionario de clasificación por edad, la página de política de privacidad que no tienes, los tamaños de captura y el número de build que tiene que ser mayor que el anterior. El agente de envíos existe para hacer esa parte. Esto es lo que hace de verdad, paso a paso, y dónde se detiene a esperarte.

La versión corta: lee tu repositorio, prepara la ficha de la tienda, comprueba el lanzamiento contra las cosas por las que las tiendas rechazan apps, construye tu build o lo recoge, lo sube y se detiene. Un primer lanzamiento nunca se envía a revisión sin tu aprobación. Una actualización puede ir directa a revisión, pero solo si elegiste ese camino y aprobaste la ficha.

Lo que conectas una vez

Tres conexiones hacen el trabajo, y las configuras una vez por app.

GitHub. Uprate lee el repositorio a través de la API de GitHub para detectar la app y analizarla. No clona tu código, no muestra tu fuente en su interfaz y no abre pull requests contra él, con una excepción que se explica más abajo.

Una clave de tienda para publicar. Para la App Store añades en Ajustes una clave de API de App Store Connect, separada de la que lee reseñas. Uprate la valida listando las apps a las que llega, la guarda cifrada y te muestra qué apps puede publicar esa clave. Para Google Play conectas una cuenta de servicio para el paquete, la misma conexión que usa la bandeja de reseñas. Si construyes con Expo, conectas también la cuenta de Expo propietaria del proyecto.

Quién puede pulsar el botón. En un equipo, los propietarios y los miembros pueden lanzar un envío. Los asientos de revisor y de analítica pueden abrir el proceso y leer cada paso, pero no iniciarlo, enviarlo ni cancelarlo.

Añadir la app

Eliges un repositorio y Uprate busca la app en él: package.json, app.json o app.config, el Info.plist de iOS y el proyecto de Xcode, el build.gradle de Android y el manifiesto. Con eso rellena el nombre de la app, el bundle ID de iOS, el paquete de Android y el proyecto de Expo, y en un monorepo pregunta en qué carpeta vive la app. Puedes corregir cualquier cosa que haya detectado mal antes de crear la app.

iOS y Android son carriles separados. Apple puede aprobar mientras Google pide más, así que cada tienda tiene su propio proceso, con su estado y sus acciones, y una app que solo tiene bundle de iOS muestra un solo carril. Hay un envío en curso por tienda y por app; si ya hay uno abierto, el botón de lanzar te lleva a él en vez de abrir un segundo.

Dónde debe detenerse

Cada lanzamiento empieza con una pregunta, y la respuesta decide hasta dónde llega el proceso por su cuenta.

Plan	Qué pasa	Dónde espera
Probar primero (por defecto)	Prepara la ficha, ejecuta las comprobaciones, construye o recoge tu build y lo sube a TestFlight o a las pruebas internas de Google Play. Nada llega a App Review.	En "Ready to submit", hasta que pulsas enviar.
Ir en vivo	Lo mismo, y después continúa a la revisión de la tienda. En un primer lanzamiento apruebas antes los datos preparados de la tienda; en una actualización se te muestra la ficha antes de escribirla.	En nada después del build, salvo que falle una comprobación.
Solo comprobar (App Store)	Recorre cada paso e informa de lo que haría un lanzamiento real. No se construye nada ni cambia nada en Apple.	Termina con "Check complete".

La segunda pregunta es de dónde sale el build. Con Build with Expo, Uprate construye desde tu repositorio. Con Upload IPA o Upload AAB, arrastras un build firmado desde tus propias herramientas; Uprate lo valida, lee de él la versión y el número de build y sube el de iOS con Transporter de Apple. Con Use ASC build o Use Google Play build, eliges un build que ya está procesado en la consola de la tienda, que es el camino de quien sube desde Xcode o desde su propia CI.

Una salvedad en Android: los builds desde el repositorio necesitan un runner aislado, y ese runner no forma parte del producto alojado, así que los procesos de Android usan hoy un AAB o APK subido, o un build que ya está en Google Play.

Qué produce el análisis en un primer lanzamiento

Un primer lanzamiento es el caso en el que la app todavía no existe en la tienda, y ahí ocurre la mayor parte del análisis. Uprate lee una porción acotada del repositorio, app.json, package.json, el README y un puñado de extractos de código, y pasa ocho analizadores por encima.

El texto de la ficha vuelve como nombre y subtítulo dentro de los 30 caracteres de Apple, una descripción breve para Google Play, una descripción por debajo de 4.000 caracteres, palabras clave por debajo de 100 caracteres, texto promocional y las URL de soporte y marketing que encontró. Las categorías y el cuestionario de clasificación por edad se responden a partir de lo que hace la app. La pregunta sobre cifrado de exportación se responde desde el código, con la evidencia que usó. Las etiquetas de privacidad se proponen a partir de las dependencias y de las API que llama el código, de nuevo con rutas de archivo y fragmentos como evidencia. Se generan una política de privacidad y unos términos de servicio, alojados en una página pública de Uprate, porque la tienda necesita una URL y la mayoría de las apps nuevas no la tienen. Por último, una auditoría ASO lee todo el conjunto y lista los problemas como críticos, mayores, menores o informativos, y marca la jerga técnica en textos para usuarios, para que "hecho con React Native y TypeScript" no acabe en una descripción.

Todo lo que produce el análisis es editable en el proceso, por idioma, y sigue siendo una sugerencia hasta que lo apruebas.

Las actualizaciones se saltan casi todo esto. La ficha se toma de lo que está en vivo en la tienda, la respuesta sobre cifrado de exportación se vuelve a derivar del código porque Apple la pide en cada build, el escaneo de privacidad sigue corriendo para que tengas una sugerencia basada en el código que comparar con las etiquetas que ya tienes, y el texto de "Novedades" se redacta a partir de los commits desde el último lanzamiento.

Las comprobaciones antes de construir nada

Antes de que empiece un build, el proceso pasa una lista de comprobación contra la tienda y el repositorio. Confirma que la configuración de Expo y eas.json existen y son válidos, que el propietario de Expo coincide con tu cuenta, que la versión de la app y el número de build son mayores que los que ya tiene App Store Connect, que el bundle ID de la configuración coincide con la tienda, que la respuesta de cifrado, la clasificación por edad y la categoría principal están definidas, que la URL de la política de privacidad es pública y carga de verdad, y que los tamaños de captura que exige la tienda están cubiertos. Cada punto fallido es una frase con el campo a corregir, y puedes volver a ejecutar el paso después de corregirlo.

Una segunda pasada lee el repositorio buscando las cosas por las que App Review devuelve apps: textos de permiso que faltan para cámara, fotos, ubicación, contactos o micrófono, un permiso de rastreo en apps que parecen rastrear, inicio de sesión de terceros sin Iniciar sesión con Apple, cuentas sin una forma de borrarlas dentro de la app, metadatos de compras integradas y contenido generado por usuarios sin denuncia ni moderación.

La tercera pasada es la comprobación de App Review. Toma la evidencia de las pasadas anteriores y los metadatos preparados y los comprueba contra un conjunto curado a mano de 26 reglas de las App Review Guidelines de Apple. El resultado es una lista de hallazgos, cada uno un riesgo o un aviso, cada uno citando la evidencia en la que se basa y la directriz a la que corresponde. Las reglas que no pudo verificar se listan como no verificadas en vez de adivinarse. Esta comprobación nunca bloquea un envío por sí sola y nunca informa de una probabilidad de rechazo.

Problemas, no puntuaciones Uprate no muestra un porcentaje de preparación ni una puntuación de riesgo. Muestra recuentos de problemas, cada uno con el campo y la solución. Cuando falla un paso, "Copy fix prompt" produce un prompt con el diagnóstico y las referencias de archivo para tu propio agente de código. Uprate no escribe código en tu repositorio.

Escribir en la tienda, y la pausa

Una vez aprobada la ficha, el proceso la escribe en la tienda a través de su API: la versión, los textos de la ficha en cada idioma, las categorías, la clasificación por edad y el conjunto de capturas que adjuntaste. El precio y la disponibilidad se comprueban y se fijan antes del envío a revisión. Si la app aún no existe en App Store Connect, primero se registra el bundle ID y se crea el registro de la app. Una cosa no se escribe: las etiquetas de privacidad de Apple no tienen API pública, así que Uprate muestra su sugerencia y te pide confirmar que las rellenaste en App Store Connect antes de que un primer lanzamiento siga adelante. Mientras un proceso escribe, construye o está en revisión, el editor de la ficha de esa app queda bloqueado para que los dos no se pisen.

Con Build with Expo en iOS, Uprate abre un único pull request en tu repositorio que añade un archivo de flujo bajo .eas/workflows/. Lo fusionas, y desde entonces Uprate lanza ese flujo a través de la GitHub App de Expo para un commit concreto. El flujo construye el binario de producción y lo envía a App Store Connect usando el servicio de credenciales de Expo, así que ninguna clave de App Store Connect acaba en los secretos de tu repositorio. Es el único sitio donde Uprate toca tu repositorio, y es un archivo de flujo, no tu código.

El build se sube a TestFlight o a pruebas internas. En el plan por defecto el proceso se aparca entonces en "Ready to submit". Instalas el build, lo pruebas y pulsas enviar cuando estás conforme. Con "Ir en vivo" el proceso continúa a revisión. En Google Play, una cuenta que aún tiene el requisito de pruebas cerradas de Google cae en "Live on internal testing", y el proceso sigue vigilando y pasa a aprobado por sí solo cuando el lanzamiento de producción está en vivo.

En revisión, y después

Uprate consulta el estado de la revisión y muestra el proceso como una línea por fase, con los detalles de cada evento tras un desplegable. Aprobado es aprobado. Un rechazo se muestra con los detalles de estado de Apple traducidos a lenguaje claro, más un enlace a Review Issues & Messages de App Store Connect, porque el mensaje completo sobre la directriz no se expone por la API. Corrige la app o la ficha y pulsa reenviar, con una nota si quieres dejar constancia de lo que cambió.

Un paso fallido no es un proceso fallido. El proceso te dice qué paso falló y te ofrece continuar desde ahí o intentarlo de nuevo. También puedes cancelar un proceso, incluso uno que ya está en la cola de Apple, donde Uprate retira el envío a revisión por ti.

Qué cuesta

El agente de envíos está disponible en todos los planes, incluido el gratuito. El análisis del repositorio en un primer lanzamiento es una acción de 5 créditos para todo el conjunto de analizadores, la auditoría ASO son otros 5, y un prompt de corrección son 2. Los builds corren en tu cuenta de Expo o vienen de ti, así que no se cuentan en créditos de Uprate.

Dónde encaja

El agente de envíos es lo segundo que se configura después de conectar las tiendas. De qué te protege está en Cuánto tarda la revisión de la App Store y en las guías de rechazos de este blog, y cómo convive con la bandeja de reseñas y los borradores de ficha en Cómo llevar las operaciones de tienda sin contratar a alguien de ops.