LaunchLint Academy
La respuesta breve
- Publicar en producción en Google Play es mucho más que subir un Android App Bundle. La ficha, App content, Data safety, las pruebas, la firma y el despliegue deben describir el mismo build y resolver todos los avisos bloqueantes.
- Esta guía acompaña a equipos Expo y React Native desde una versión candidata congelada hasta un lanzamiento controlado, con evidencias, responsables, criterios de parada y monitorización posterior.
- Justo antes de producción, realiza un ensayo con funciones claras. Una persona opera Play Console, otra instala exclusivamente el artefacto del track previsto y una tercera observa monitoring y backend. Empieza con una cuenta nueva, prueba actualización e instalación limpia, provoca al menos un error controlado y confirma soporte y privacidad. Compara la app visible con ficha, capturas, Data safety y notas. Registra hora, build, dispositivos, resultados y excepciones. El candidato solo pasa a producción cuando cada diferencia tiene responsable y decisión explícita.
- Archiva únicamente resultados verificables: estado de consola, ID del artefacto, informe de pruebas, matriz aprobada y decisión de rollout. Nunca incluyas claves, secretos de firma o datos personales de prueba. Revisa además quién puede editar producción y elimina permisos temporales al terminar; una release técnicamente correcta sigue siendo frágil si demasiadas cuentas pueden modificarla sin revisión.
Congelar la versión candidata
Marca un commit como candidato y evita cambios silenciosos de código, configuración o dependencias nativas. Código y nombre de versión, paquete y perfil de Expo EAS deben identificar de forma inequívoca el AAB generado.
Registra suma de comprobación, enlace, commit, hora y responsable. Así testers, Play Console y equipo hablan del mismo artefacto y pueden reproducir cualquier decisión.
Registro
- Commit y versiones registrados
- Perfil y paquete verificados
- Suma y ubicación del AAB guardadas
- Sin cambios tardíos no revisados
- Responsable asignado
Verificar el bundle y la firma
Google Play recibe Android App Bundles y genera APK optimizados. Comprueba que se ha subido el bundle correcto y que Play App Signing está bien configurado. Un error de clave o paquete no es una simple corrección de metadatos.
En Expo, verifica perfil de producción, credenciales e identificador antes de construir. No cambies una clave de firma de forma improvisada para ocultar un fallo de carga.
Bundle y firma
- Publicar AAB, no APK local
- Revisar Play App Signing
- Confirmar nombre de paquete
- Inspeccionar artefacto subido
- No exponer credenciales
Revisar toda la ficha de Play
Título, descripciones, icono, gráfico destacado, capturas, contacto y privacidad deben estar completos. Cada promesa ha de coincidir con el candidato; imágenes de prototipo o funciones retiradas aumentan riesgo de revisión y pérdida de confianza.
Revisa cada idioma por separado. Una ficha predeterminada completa puede ocultar recursos localizados antiguos. Mantén una matriz con idioma, recurso, responsable y fecha.
Ficha
- Textos acordes al producto
- Gráficos actuales
- Enlaces de privacidad y soporte válidos
- Idiomas revisados
- Contacto atendido
Completar App content y Data safety
App content reúne privacidad, anuncios, acceso restringido, público, permisos, clasificación, Data safety y otras declaraciones. Son afirmaciones públicas y relevantes para la revisión, no un trámite administrativo.
Deriva las respuestas del código, inventario de SDK y flujos de backend. Si analítica o publicidad procesa datos, el formulario debe reflejarlo. El cuestionario no sustituye la evidencia técnica.
App content
- Anuncios y público correctos
- Acceso para revisión preparado
- Permisos explicados
- Data safety verificado técnicamente
- Clasificación completa
Usar pruebas internas y cerradas
Una prueba interna permite controles rápidos; una cerrada amplía dispositivos y uso real. Instala la versión distribuida por Play para probar firma, división del bundle, actualizaciones y contexto de tienda, no solo un debug local.
Define criterios para primer inicio, sesión, flujo principal, compras, permisos, enlaces profundos, modo sin conexión y errores. Cada incidencia debe incluir build y dispositivo.
Cobertura
- Instalar desde Play
- Probar instalación y actualización
- Cubrir flujo y errores
- Verificar compras y deep links
- Adjuntar build y dispositivo
Evaluar el informe previo
El informe previo ejecuta bundles en dispositivos y puede revelar estabilidad, rendimiento, accesibilidad y seguridad. Es una señal adicional, no un reemplazo de pruebas específicas del producto.
Clasifica cada resultado como bloqueo reproducible, riesgo, limitación conocida o falso positivo y documenta la decisión. Los avisos ignorados sin motivo reaparecen y pierden valor.
Triage
- Reproducir crashes y ANR
- Valorar rendimiento y accesibilidad
- Asignar seguridad
- Documentar falsos positivos
- Cerrar bloqueos
Controlar el despliegue en producción
Crea la release solo cuando ficha y App content estén completos y no existan errores bloqueantes. Las notas deben explicar con precisión el cambio visible.
Un despliegue gradual limita el impacto de defectos desconocidos. Define porcentaje inicial, ventana, responsable y umbrales de parada antes de avanzar; sin gates solo es un lanzamiento total más lento.
Gate de despliegue
- Sin errores bloqueantes
- Notas exactas
- Porcentaje y ventana definidos
- Umbrales de pausa fijados
- Owner con autoridad
Monitorizar y documentar
Tras publicar, observa crashes, ANR, reseñas, soporte, errores del backend y funnels críticos. Compara con una base conocida para distinguir variación normal de regresiones reales.
Cierra el lanzamiento registrando versión final, horarios, etapas, anomalías y tareas pendientes. El historial acelera futuras revisiones y descubre problemas repetidos.
Operación
- Comparar métricas con base
- Observar soporte y reseñas
- Revisar backend y funnels
- Avanzar tras el gate
- Guardar aprendizajes
Preguntas frecuentes
¿Necesito un AAB?
El Android App Bundle es el artefacto estándar y Google Play genera APK optimizados a partir de él.
¿Basta con subirlo correctamente?
No. También deben completarse ficha, App content, políticas, pruebas y errores bloqueantes.
¿Conviene publicar al 100 %?
Para cambios relevantes, un despliegue gradual con umbrales definidos reduce el riesgo.
¿El informe previo sustituye QA manual?
No. Añade señales de dispositivos, pero no cubre todos los flujos del producto.
¿Qué build deben probar los testers?
Preferiblemente el distribuido por un track de Play para ejercitar firma, entrega y actualizaciones reales.