Alexgub84/publicación-tienda

publicacion-tienda

Este procedimiento se probó por última vez en Google Play Console y App Store Connect reales el 2026-11-08. Ambas consolas cambian sus pantallas, nombres de campos y navegación sin previo aviso; si algún paso a continuación no coincide con lo que ves, abre un issue en este repositorio en lugar de adivinar, y envía un PR con la corrección si la encuentras.

0. Decide en qué camino estás

Situación	Ve a
La aplicación nunca se ha enviado, no hay registro en ninguna consola	§1, luego §2, §3, §4
La aplicación ya está listada, necesita enviarse una nueva compilación	§5 (la ruta repetida)
Pregunta sobre la cuenta (individual vs organización, transferencia, nombre del paquete)	§6
El revisor no puede iniciar sesión, o la aplicación fue rechazada	§7

Regla que se aplica en todas partes: cada subida necesita notas de versión en todos los idiomas de la ficha en los que se distribuya. Nunca dejes un cuadro "Novedades" vacío: un cuadro vacío se interpreta como una compilación no probada para un revisor.

1. Lista de verificación de configuración inicial (ambas tiendas)

Haz esto en orden; cada uno desbloquea el siguiente.

1. Las cuentas de desarrollador existen y están verificadas. La aplicación debe publicarse desde la cuenta que realmente posee el producto: el editor oficial, no una cuenta compartida o de agencia utilizada en aplicaciones no relacionadas. Apple en particular rechaza aplicaciones que parecen provenir de una plantilla comercializada o un servicio de generación de aplicaciones cuando se envían bajo una cuenta que posee muchos productos no relacionados, y por separado (directriz 5.2.1) espera que el propietario de la propiedad intelectual sea quien envíe la solicitud. Consulta §6 para la decisión individual vs organización.
2. Las páginas legales están en el dominio de producción: una política de privacidad, términos de uso y una página de eliminación de cuenta si la aplicación permite el registro. Ambas tiendas solicitan estas URL; el formulario de Seguridad de datos de Google enlaza directamente la página de eliminación. Obtén la aprobación del texto legal de quien sea el propietario del producto antes de usarlo en un envío: es una decisión comercial, no técnica.
3. Un icono de aplicación real, no uno predeterminado del framework: ambas tiendas rechazan o marcan un icono predeterminado sin cambios como de baja calidad. Activos necesarios: el icono adaptativo/de primer plano dentro del binario, un icono de Play de 512×512, un gráfico de características de Play de 1024×500 y un icono de Apple de 1024×1024 en el catálogo de activos (sin transparencia; Apple lo aplana, generalmente a negro).
4. Una cuenta de demostración para revisión, si la aplicación requiere inicio de sesión. Necesita: un identificador fijo (teléfono, correo electrónico o nombre de usuario) con un código único fijo o contraseña que se respete solo para ese identificador, un estado de demostración sembrado que el revisor pueda probar realmente y sin efectos secundarios salientes (sin SMS reales, sin cobros reales). Almacena la credencial fuera de las páginas de la consola misma: nunca como texto plano pegado en las notas de Revisión de la aplicación, donde se convierte en un registro permanente y ampliamente legible. Verifica que el inicio de sesión funcione con la compilación exacta que se envía, cada vez, justo antes de enviar.
5. Un inventario de datos: un documento (en el repositorio, en una wiki, donde sea que el equipo mantenga las especificaciones) que enumere cada tipo de datos que la aplicación recopila, por qué y a través de qué SDK. El formulario de Seguridad de datos de Google y el formulario de Privacidad de la aplicación de Apple se completan A PARTIR de este documento, nunca de memoria; y cada vez que la aplicación obtiene un nuevo permiso o un nuevo SDK de análisis/diagnóstico, el inventario cambia en el mismo cambio que agrega el permiso, y ambos formularios se rehacen antes del próximo envío. Una discrepancia entre lo que dicen los formularios y lo que realmente hace el binario es una razón de rechazo común y evitable.
6. Google Play: Crear aplicación, luego recorre "Configurar tu aplicación" de arriba a abajo: URL de política de privacidad, Acceso a la aplicación (público o restringido con la cuenta de revisión e instrucciones), declaración de anuncios, cuestionario de clasificación de contenido (respondido con sinceridad según el comportamiento real de la aplicación), audiencia objetivo y edad, declaración de aplicaciones gubernamentales, declaración de características financieras, declaración de salud, Seguridad de datos (del inventario), declaración de ID de publicidad. Acepta la firma de Play App para que Google mantenga la clave de firma de la aplicación y la clave de subida siga siendo reemplazable. Completa la ficha principal de la tienda (nombre, descripciones, icono, gráfico de características, al menos 2 capturas de pantalla de teléfono). Luego crea una pista de pruebas cerradas y una versión antes de tocar producción.
7. Apple: registrar el ID de aplicación explícito, crear el registro de la aplicación en App Store Connect (nombre, SKU, idioma principal), completar Información de la aplicación (categoría, derechos de contenido, clasificación por edad), Privacidad de la aplicación (del inventario), Precios y disponibilidad, la página de versión (capturas de pantalla, descripción, palabras clave ≤ 100 caracteres, URL de soporte, derechos de autor), Información de revisión de la aplicación (instrucciones de inicio de sesión si es necesario, contacto de revisión, notas) y elegir una opción de lanzamiento (el lanzamiento manual es la opción predeterminada más segura: coloca la decisión de "publicar" en un clic separado y deliberado después de la aprobación). Para compilaciones de TestFlight, responde la pregunta de cumplimiento de exportación cada vez o agrega ITSAppUsesNonExemptEncryption=false a Info.plist una vez si es cierto, para evitar que la pregunta se repita.
8. Envía ambas temprano. La revisión toma de horas a días en cada tienda, y la primera revisión suele ser donde surgen los problemas reales: presupuesta al menos un rechazo y un reenvío, especialmente en Apple.

2. Creación del paquete de lanzamiento

Sea cual sea la cadena de herramientas (Flutter, React Native, Expo o un proyecto nativo Swift/Kotlin), compila desde una copia limpia del commit exacto que se va a lanzar, nunca desde un directorio de trabajo con cambios sin confirmar. Las ediciones sin confirmar que se filtran en un binario de la tienda son muy difíciles de notar después.

• Android: produce un AAB firmado de lanzamiento (nunca un APK para una subida a la tienda), con un número de compilación (versionCode o equivalente) estrictamente superior al último enviado. Verifica que el nombre del paquete incrustado en el paquete coincida con el que posee la cuenta de Play de destino antes de subir: un nombre de paquete no coincidente falla en el paso de subida.
• iOS: archiva y exporta (o sube directamente a App Store Connect desde el paso de archivo), firmado bajo la membresía correcta del Programa de desarrolladores de Apple (el "equipo" al que pertenecen tanto los certificados de la aplicación como el registro de la aplicación), con un número de compilación estrictamente superior al último enviado y el identificador de paquete exacto con el que se creó el registro de App Store Connect. La firma automática bajo el equipo correcto evita la mayoría de los problemas de certificados.
• Ambos: apunta la compilación a la API/backend de producción, no a una de prueba o local; verifica que esto esté realmente integrado en el binario, no solo pasado como una bandera de compilación que podría pasar silenciosamente a un valor predeterminado. Mantén iOS y Android en el mismo número de compilación/versión cuando el producto tenga una cadena de versión compartida, para que una conversación de soporte sobre "versión 2.3" signifique lo mismo en ambas plataformas.

3. Capturas de pantalla

Solo capturas reales: la directriz 2.3.3 de Apple rechaza explícitamente maquetas y composites de marketing presentados como capturas de pantalla. El patrón confiable es una prueba de interfaz de usuario automatizada que ejecuta la aplicación real, inicia sesión con la cuenta de revisión en un backend real (no simulado), navega a cada pantalla y captura el fotograma, nunca una foto de un simulador tomada con un teléfono en mano.

Tamaños de dispositivo típicos a cubrir (verifica los requisitos actuales de la tienda antes de confiar en estos; cambian): un iPhone grande moderno (el requisito "más grande" actual de Apple), un iPad si la aplicación es compatible con iPad, y un teléfono Android representativo y/o tableta para Play. Apple deriva tamaños de iPhone más pequeños del conjunto más grande automáticamente en la mayoría de los casos.

Elige un conjunto pequeño (5-8 imágenes) que cuente la historia del producto en orden: una vista de lista o inicio, una pantalla estructural central, una vista de unidad/detalle individual, el flujo de trabajo principal en progreso, un estado completado/éxito y configuración si corresponde. Omite las pantallas de inicio de sesión simples y los estados vacíos: no dicen nada sobre lo que hace la aplicación.

Problemas conocidos, independientes de la cadena de herramientas:

• Una compilación de depuración a menudo muestra una barra o marca de agua de depuración visible; apágala antes de capturar.
• Una sesión de simulador o emulador puede mantener un inicio de sesión anterior entre reinstalaciones; cierra la sesión explícitamente dentro de la prueba o borra el estado del simulador/emulador primero.
• Volver a navegar a la pantalla "misma" con diferentes parámetros a veces no vuelve a renderizar una pantalla con estado correctamente; navega a través de una pantalla principal entre capturas.
• Ejecutar dos sesiones de captura desde el mismo directorio del proyecto al mismo tiempo tiende a chocar con los artefactos de compilación generados; usa copias de trabajo separadas si se ejecutan en paralelo.

4. Flujo de actualización (aplicación ya listada)

Consulta §5 para la lista de verificación dedicada de lanzamiento repetido. La versión corta: una nueva compilación obtiene un número de compilación estrictamente superior al último enviado, el diff del inventario de datos desde el último lanzamiento decide si los formularios de privacidad necesitan actualizarse, las notas de versión nunca se saltan y la cuenta de demostración de revisión se vuelve a verificar en el entorno exacto al que apunta el nuevo binario antes de cada envío.

5. La ruta repetida: un lanzamiento cuando la aplicación ya está en vivo

Un lanzamiento = un pase por esta lista, de arriba a abajo.

Precondiciones (detente si alguna falla)

• El código que se envía está realmente desplegado en producción, con las migraciones de base de datos ya aplicadas: un despliegue y una migración no son el mismo paso, y desplegar antes de migrar (o no migrar en absoluto) produce una compilación que se comunica con un backend que no está listo para ella.
• La cuenta de demostración de revisión inicia sesión en producción y alcanza el estado de demostración que un revisor necesitaría ver.
• Se verifica el diff del inventario de datos desde la última compilación enviada. Cualquier nueva fila significa que los formularios de privacidad cambian ANTES de enviar, no después de que un rechazo lo señale.
• El espacio de versión de Apple está libre. Si una versión anterior está en "Pendiente de lanzamiento del desarrollador" o aún en revisión, App Store Connect no te permitirá crear la siguiente fila de versión. Primero lanza o cancela la versión pendiente; no existe la opción "mantener esta, enviar la compilación más nueva en su lugar".
• La cadena de versión y el número de compilación están decididos: número de compilación = último enviado + 1 en cada plataforma; la cadena de versión solo aumenta para un cambio que un usuario realmente notaría.

Notas de versión

Escríbelas a partir de lo que realmente se envió (los cambios fusionados desde el último lanzamiento), solo elementos visibles para el usuario, aproximadamente 4-8 viñetas, en todos los idiomas que admita la ficha: verifica qué idiomas tiene realmente la ficha antes de asumir que necesita varios; una ficha con solo un idioma configurado rechazará un campo de notas de versión para un idioma que no tiene más. En Apple, agregar un nuevo idioma completo a una ficha es un proyecto propio (nombre, subtítulo, descripción, palabras clave y su propio conjunto de capturas de pantalla); nunca asumas que es solo un cambio de cuadro de texto.

Capturas de pantalla

Solo rehazlas si las pantallas realmente cambiaron de una manera que un comprador notaría. De lo contrario, deja el conjunto existente como está. Si reemplazas, reemplaza todo el conjunto en el mismo orden que antes en lugar de agregar: la mayoría de las consolas limitan la cantidad de capturas de pantalla por ficha, por lo que el reemplazo parcial corre el riesgo de alcanzar ese límite.

Consolas

Google Play: si el inventario cambió, actualiza primero el formulario de Seguridad de datos. Luego: la pista de prueba o producción correspondiente → crear una nueva versión → subir el AAB → notas de versión en todos los idiomas configurados → revisar la versión → iniciar el despliegue (trata "iniciar despliegue" como una acción deliberada y confirmada; es el clic irreversible en el flujo de Play). Un despliegue en producción se puede escalonar por porcentaje y pausar si algo parece mal después de unos pocos porcentajes.

Apple App Store Connect: adjunta la nueva compilación a TestFlight primero (cumplimiento de exportación, "qué probar"), luego edita la página de versión existente (si la cadena de versión no ha cambiado y la versión anterior aún no se ha lanzado) o crea una nueva versión (solo posible cuando ninguna versión está actualmente en "Preparar para envío" — ver la precondición anterior). Vuelve a verificar que la Información de revisión de la aplicación sigue siendo precisa, vuelve a verificar la Privacidad de la aplicación si el inventario cambió, selecciona la nueva compilación, completa "Novedades" y envía para revisión. Trata "enviar para revisión" de la misma manera que el clic de despliegue de Play: una acción deliberada y confirmada, no algo que se deba disparar automáticamente.

Mantenimiento de registros

Cualquier registro que ya tenga el equipo para los lanzamientos (un registro de cambios, un issue de lanzamiento, una hoja de cálculo) debe incluir: los números de versión y compilación enviados, las horas de subida, la pista/etapa, quién confirmó el despliegue o envío y el resultado de la revisión una vez que se conozca. Actualiza el archivo de versión del proyecto para que coincida con lo que realmente se envió: una discrepancia aquí es exactamente cómo el próximo lanzamiento reutiliza accidentalmente un número de compilación.

Nunca estaciones una versión preparada

Una versión que está en "Preparar para envío" en App Store Connect ocupa el único espacio de versión disponible: no se puede crear una nueva versión debajo de ella. Por lo tanto: decide el destino de una versión preparada en la misma sesión en que se prepara. O la envías o no creas la fila todavía.

Si una compilación más nueva está lista mientras una versión anterior preparada todavía está estacionada, no elimines la fila estacionada ni envíes la compilación obsoleta solo para liberar el espacio. Mientras una versión está en "Preparar para envío", su cadena de versión sigue siendo un campo editable: avanza en el mismo lugar: cambia la cadena de versión a la nueva, adjunta la nueva compilación, reemplaza "Novedades". Las capturas de pantalla, las notas de revisión y las respuestas de privacidad se conservan, por lo que nada de lo preparado se desperdicia.

Una compilación de prueba (TestFlight) y un envío público son decisiones independientes: la pista de prueba interna de TestFlight en particular no necesita revisión ni ninguna fila de versión, por lo que "los probadores necesitan una compilación hoy" nunca es una razón por la que un envío público tenga que esperar, y un envío público pendiente nunca es una razón por la que los probadores tengan que esperar.

6. Cuentas, transferencias, nombres de paquetes

• Una cuenta de desarrollador personal de Google Play creada después del límite de política (13 de noviembre de 2023 en el momento de escribir esto; consulta la política actual) debe completar una prueba cerrada con un mínimo de...