Cuenta de desarrollador
Para publicar en Play Store necesitás una cuenta de Google Play Developer. El proceso:
- Ir a play.google.com/console
- Pagar el registro único de USD 25
- Completar la verificación de identidad (proceso que puede tardar días)
- Aceptar los términos del Developer Distribution Agreement
La verificación de identidad es obligatoriaDesde 2023, Google requiere verificar identidad (documento de identidad o información de empresa) para publicar apps. El proceso puede tardar entre 1 y 7 días. Tenerlo en cuenta si tenés una fecha de lanzamiento.
Crear la app en Play Console
En Play Console → Crear app. Completás:
- Nombre de la app: el que ven los usuarios en Play Store
- Idioma predeterminado
- App o juego
- Gratuita o de pago — no se puede cambiar de gratuita a paga después
Después de crear, el Panel de Control te muestra una lista de tareas pendientes antes de poder publicar. Muchas son obligatorias.
Ficha de Play Store
La ficha es lo que ven los usuarios antes de descargar. Afecta directamente las conversiones y el posicionamiento en búsquedas:
- Título: hasta 30 caracteres. Las primeras palabras son las más importantes para búsqueda.
- Descripción corta: hasta 80 caracteres. Aparece en la vista de lista.
- Descripción larga: hasta 4000 caracteres. Podés usar HTML básico.
- Ícono: 512x512 px, PNG, sin transparencia en las esquinas.
- Screenshots: mínimo 2, máximo 8. Son el factor #1 de conversión.
- Feature graphic: 1024x500 px. Banner que aparece cuando la app es destacada.
A/B testing de fichasPlay Console permite hacer A/B testing del ícono, screenshots y descripción para ver qué versión convierte mejor. Es una feature muy subutilizada que puede mejorar significativamente las instalaciones sin tocar código.
Tracks de lanzamiento
Play Store tiene cuatro tracks para lanzar builds progresivamente:
# Tracks de menor a mayor exposición:
# 1. INTERNO (Internal testing)
# - Hasta 100 testers con email en lista blanca
# - Disponible en minutos (no requiere revisión de Google)
# - Ideal para equipo de desarrollo y QA
# 2. CERRADO (Closed testing / Alpha)
# - Grupos de testers por email o Google Groups
# - Requiere revisión de Google (horas a días)
# - Puede tener múltiples pistas cerradas (alpha, beta privada, etc.)
# 3. ABIERTO (Open testing / Beta)
# - Cualquier usuario puede optar por ser tester
# - Aparece en Play Store con badge "Beta"
# - Requiere revisión de Google
# 4. PRODUCCIÓN
# - Todos los usuarios de Play Store
# - Requiere revisión de Google (1-7 días la primera vez, horas las siguientes)
# - Soporta staged rollout (lanzamiento gradual)Track interno — el flujo de trabajo diario
El track interno es tu mejor amigo durante el desarrollo. Está disponible en minutos, sin revisión. El flujo recomendado:
# 1. Generar AAB de release
./gradlew bundleRelease
# 2. Subir a track interno en Play Console:
# Release → Testing → Internal testing → Create new release
# Subir el .aab, agregar release notes, Save → Review → Start rollout
# 3. Testers abren el link de opt-in que genera Play Console
# (una sola vez por tester)
# 4. Actualización disponible en Play Store en ~5-10 minutos
# Automatizar con Fastlane (lección complementaria recomendada):
# fastlane supply --aab app-release.aab --track internalversionCode debe incrementar siemprePlay Store rechaza un build si el versionCode no es mayor al último subido. Automatizalo en build.gradle usando el número de commit de git o un contador en CI/CD.
Subir a producción por primera vez
La primera revisión suele tardar entre 1 y 7 días. Google revisa:
- Que la app funcione y no crashee en dispositivos de prueba
- Que la ficha sea precisa y no engañosa
- Que los permisos declarados sean justificables
- Que cumpla las políticas de contenido
Para las actualizaciones siguientes, si no hay cambios de permisos ni contenido sensible, la revisión suele tardar horas.
# Checklist antes de subir a producción:
# ✓ versionCode incrementado
# ✓ versionName actualizado (ej: "1.2.0")
# ✓ R8 habilitado (minifyEnabled = true)
# ✓ No hay logs sensibles en release
# ✓ URLs apuntan a producción (no a staging)
# ✓ Firebase apunta al proyecto correcto
# ✓ Release notes escritas en todos los idiomas soportados
# ✓ El AAB fue testeado en el track internoStaged rollout — lanzamiento gradual
En lugar de lanzar a todos los usuarios de una vez, podés hacer un rollout gradual. Empezás con un porcentaje pequeño y lo aumentás si no aparecen problemas:
# Flujo típico de rollout:
Día 1: → 5% de usuarios (monitorear Crashlytics y ratings)
Día 2: → 20% de usuarios (si todo bien)
Día 3: → 50% de usuarios
Día 5: → 100% de usuarios
# Los usuarios que YA tienen la app actualizada no vuelven atrás
# Solo los que aún no actualizaron reciben la nueva versión a medida que suben el %Revertir un release
Si aparece un bug crítico en producción, tenés dos opciones:
# Opción 1: Pausar el rollout (si está en staged rollout)
# Play Console → Release → Managed publishing → Halt rollout
# Los usuarios que no actualizaron quedan en la versión anterior
# Opción 2: Publicar un hotfix rápidamente
# Corregir el bug → incrementar versionCode → generar AAB → subir
# Con el track interno podés validar en minutos antes de ir a producción
# ⚠️ NO se puede bajar la versión de los usuarios que ya actualizaron
# Google no permite forzar downgrades. Por eso el staged rollout existe.No existe el "rollback" realUna vez que un usuario actualizó, quedó en esa versión. Lo único que podés hacer es publicar una nueva versión con el fix. Por eso es importante el staged rollout y monitorear Crashlytics en las primeras horas después de cada release.