Cómo publicar tu primera app en Play Store

Antes de empezar: lo que necesitás tener listo

Publicar en Play Store no es apretar un botón — hay trabajo de preparación. Si llegás a Play Console sin tener estas cosas listas, vas a tener que volver a empezar a mitad del proceso.

• La app funciona y no crashea en al menos 3-4 dispositivos o emuladores distintos. Android fragmentación real: lo que anda en tu Pixel puede fallar en un Samsung de gama baja.
• Un keystore creado y guardado de forma segura. Si lo perdés después de publicar, no podés publicar actualizaciones. Sin excepciones.
• Un ícono de 512x512 px en PNG, sin transparencia en las esquinas si es circular.
• Capturas de pantalla — mínimo 2, máximo 8 por tipo de dispositivo (teléfono, tablet). Son el factor #1 que determina si alguien descarga tu app.
• Descripción escrita — corta (80 caracteres) y larga (hasta 4000 caracteres). Si no las tenés escritas de antemano, vas a escribir algo apresurado que va a quedar así para siempre.
• Una cuenta de Google dedicada al desarrollo, separada de tu cuenta personal.

Cuenta de desarrollador — lo que no te dicen

Ir a play.google.com/console, pagar USD 25 y listo, ¿no? Casi. Hay pasos que pueden sorprenderte:

Verificación de identidad (obligatoria desde 2023)

Google ahora requiere verificar tu identidad antes de poder publicar. El proceso pide un documento de identidad (DNI, pasaporte) o información de empresa. El resultado puede tardar entre 1 hora y varios días dependiendo de la carga del sistema y del país.

Si tenés una fecha de lanzamiento comprometida, iniciá el proceso de verificación con al menos una semana de anticipación.

Cuenta personal vs cuenta de organización

Al registrarte elegís si es una cuenta personal o de organización. La diferencia visible para el usuario: las apps de cuentas de organización muestran el nombre de la empresa como desarrollador. Las personales muestran tu nombre real o el nombre que elijas.

Podés cambiar el nombre del desarrollador después, pero el tipo de cuenta (personal/organización) es difícil de cambiar. Si pensás publicar apps comercialmente o en nombre de una empresa, registrá como organización desde el principio.

El pago de USD 25

Es un pago único, no recurrente. No tiene fecha de vencimiento. Podés publicar ilimitadas apps con esa cuenta. En Argentina podés pagarlo con tarjeta internacional o a través del sistema de pagos locales de Google si está disponible.

Preparar la app para producción

Antes de generar el build final, hay un checklist técnico que vale la pena revisar:

// build.gradle (app) — configuración de release
android {
    defaultConfig {
        applicationId = "ar.pensa.miapp"  // NO cambiar después de publicar
        minSdk = 24           // cubre >95% de dispositivos activos
        targetSdk = 35        // siempre el SDK más reciente que Google exija
        versionCode = 1       // entero, se incrementa en cada release
        versionName = "1.0.0" // string visible para el usuario
    }

    buildTypes {
        release {
            isMinifyEnabled = true    // R8 ofuscación + shrinking
            isShrinkResources = true  // eliminar recursos no usados
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

Cosas adicionales a verificar antes del build de release:

# Checklist pre-release:
# ✓ Ningún Log.d() con datos sensibles (token, contraseñas, emails)
# ✓ URLs apuntan a producción, no a localhost ni staging
# ✓ Claves de API de producción (no de desarrollo)
# ✓ Firebase apunta al proyecto correcto
# ✓ targetSdk cumple el mínimo que exige Play Store (actualmente 34+)
# ✓ Probado en dispositivo físico, no solo en emulador
# ✓ Probado con la pantalla del dispositivo más pequeño que soportás

El keystore — lo más importante de todo

El keystore es el archivo que firma tu app. Android usa esa firma para verificar que las actualizaciones vienen del mismo autor. Sin el keystore original, no podés publicar actualizaciones.

# Crear el keystore (una sola vez, guardarlo para siempre):
keytool -genkeypair \
  -v \
  -keystore mi-app-release.keystore \
  -alias mi-app \
  -keyalg RSA \
  -keysize 2048 \
  -validity 10000

# El comando va a pedir:
# - Contraseña del keystore (guardala en un gestor de contraseñas)
# - Contraseña de la clave (puede ser igual a la del keystore)
# - Tu nombre
# - Nombre de tu organización (podés poner "N/A")
# - Ciudad, estado, país (AR para Argentina)

Después de crearlo, guardalo en al menos tres lugares: un gestor de contraseñas con las credenciales, un backup en la nube cifrado (Google Drive, iCloud, Dropbox), y opcionalmente en un disco externo.

Generar el Android App Bundle

Play Store requiere AAB (no APK) para nuevas apps desde agosto 2021.

# Desde Android Studio:
# Build → Generate Signed Bundle / APK
# → Android App Bundle → Next
# → Seleccionar el keystore → Next
# → Elegir "release" → Finish
# El .aab queda en: app/build/outputs/bundle/release/app-release.aab

# Desde línea de comandos:
./gradlew bundleRelease
# El .aab queda en: app/build/outputs/bundle/release/app-release.aab

Antes de subir a Play Store, probá el AAB en un dispositivo real para asegurarte de que funciona correctamente en release:

# Instalar el AAB en un dispositivo con bundletool:
java -jar bundletool.jar build-apks \
  --bundle=app-release.aab \
  --output=app.apks \
  --ks=mi-app-release.keystore \
  --ks-pass=pass:TU_CONTRASEÑA \
  --ks-key-alias=mi-app \
  --key-pass=pass:TU_CONTRASEÑA

java -jar bundletool.jar install-apks --apks=app.apks

Play Console paso a paso

Entrás a play.google.com/console y creás una app nueva. Play Console te muestra un dashboard con "tareas" pendientes. Hay que completarlas todas antes de poder publicar en producción.

Las secciones principales que vas a recorrer:

• Presencia en Play Store: la ficha — nombre, descripción, capturas, ícono.
• Clasificación de contenido: cuestionario sobre el contenido de tu app.
• Público objetivo: si la app es para menores, hay requisitos adicionales.
• Declaraciones de privacidad: política de privacidad + declaración de acceso a datos.
• Anuncios: si la app tiene publicidad.
• Distribución: en qué países disponible.
• Lanzamiento: acá subís el AAB y elegís el track.

La ficha de Play Store — lo que sí importa

La ficha es lo que el usuario ve antes de descargar. La mayoría de los devs la hacen en 10 minutos apresurados y se nota. Vale la pena invertir tiempo acá.

Nombre de la app (30 caracteres)

Las primeras palabras son las que más pesan para las búsquedas. Si tu app se llama "Mi App de Recetas", "Recetas" es más importante que "Mi App". No pongas frases como "La mejor app de..." — Google las puede rechazar.

Descripción corta (80 caracteres)

Aparece en la vista de lista, antes de que el usuario entre a la ficha completa. Tiene que explicar qué hace la app en una oración. No desperdicies estos 80 caracteres con el nombre de la app otra vez.

Descripción larga (hasta 4000 caracteres)

Podés usar HTML básico (<b>, <i>, listas). Las primeras 3-4 líneas son las más importantes porque son las que se muestran sin expandir. Empezá por el beneficio principal, no por la lista de features.

Capturas de pantalla — lo más importante

Los estudios de UX de Google muestran que las capturas de pantalla son el factor #1 en la decisión de descarga, por encima del nombre y la descripción. No pongas capturas genéricas del dispositivo — diseñá imágenes que muestren el valor de la app con texto superpuesto que explique qué está pasando.

# Requisitos técnicos de las capturas:
# Teléfono:  mínimo 320px, máximo 3840px en el lado más largo
#            relación de aspecto entre 16:9 y 9:16
#            PNG o JPEG
# Tablet 7": mismas dimensiones pero relación diferente
# Tablet 10": idem

# Recomendado: 1242 x 2688 px (iPhone XS Max) o similar
# Aunque es para Android, las capturas altas de resolución se ven mejor

# Herramientas para hacer capturas profesionales:
# - Figma con el plugin "Mockup"
# - DaVinci Resolve para agregar texto a screenshots reales
# - screely.com — envolver screenshots en marcos de dispositivo

Clasificación de contenido — lo que no podés omitir

Google te hace responder un cuestionario sobre el contenido de tu app para asignar la clasificación de edad (Apto para todos, +3, +7, +12, +16, +18). No podés saltear esto.

Las preguntas incluyen: ¿tiene violencia?, ¿tiene contenido sexual?, ¿tiene lenguaje ofensivo?, ¿permite comunicación entre usuarios?, ¿tiene compras dentro de la app?

Política de privacidad — obligatoria

Necesitás una URL pública que apunte a tu política de privacidad. Sin esto no podés publicar. Si tu app no recopila ningún dato, igual necesitás una política que lo declare.

Opciones para generar una política simple:

• privacypolicygenerator.info — gratuito, genera HTML básico
• app-privacy-policy-generator.firebaseapp.com — específico para apps móviles
• Una página simple en tu sitio web o en GitHub Pages

La revisión de Google — tiempos reales

Una vez que subís el AAB y completás todas las tareas, Google revisa la app antes de publicarla. Los tiempos que la documentación no dice claramente:

# Track interno:
# → Disponible en ~minutos
# → Sin revisión de Google
# → Solo los testers en tu lista (máx 100)

# Track cerrado (Alpha):
# → 1-3 días la primera vez
# → Horas para actualizaciones sin cambios de permisos

# Track abierto (Beta):
# → 1-3 días la primera vez
# → Horas para actualizaciones normales

# Producción — PRIMERA publicación:
# → 3-7 días (puede ser más)
# → Google revisa el contenido, los permisos, la ficha, el comportamiento
# → Te pueden pedir información adicional por email

# Producción — actualizaciones:
# → Generalmente 1-24 horas
# → Si cambiás permisos, puede tardar más
# → Si el contenido cambió significativamente, más revisión

Empezá con track interno — siempre

Antes de ir a producción, subí la app al track interno y pedile a 5-10 personas que la prueben. Vas a encontrar bugs que no encontraste en desarrollo.

# Flujo recomendado para la primera publicación:

# Semana 1-2: Track interno
# - Subir el primer build firmado con release keystore
# - Dar el link de opt-in a amigos/familia/colegas
# - Corregir los bugs que encuentren
# - Iterar rápidamente (sin revisión de Google)

# Semana 3: Track cerrado (Alpha)
# - Subir el build corregido
# - Ampliar a más testers (~50 personas)
# - Esperar la revisión (1-3 días)
# - Monitorear crash rate en Crashlytics

# Semana 4-5: Producción
# - Si el crash rate es < 1%, ir a producción
# - Staged rollout al 10% primero
# - Monitorear por 24-48hs antes de subir al 100%

Por qué te rechazan — los motivos más comunes

Estos son los rechazos que más les pasan a los devs en su primera publicación:

1. Política de privacidad inaccesible o incompleta

La URL que pusiste no carga, o la política no menciona qué datos recopilás. Revisá que la URL sea pública (sin login), que cargue desde una red diferente a la tuya, y que mencione explícitamente la recopilación de datos (o la ausencia de ella).

2. Permisos no justificados

Pedís un permiso que no corresponde al uso declarado de la app. Si pedís acceso a la cámara pero no es obvio para qué la usás, Google puede rechazarte. En la ficha tenés que explicar el uso de cada permiso sensible.

3. Contenido engañoso en la ficha

La descripción promete funcionalidades que la app no tiene, o usa keywords irrelevantes para aparecer en más búsquedas ("gratis", "mejor", comparaciones con otras apps). Google tiene políticas explícitas sobre esto.

4. Íconos o capturas que imitan otras apps

Si tu ícono se parece demasiado al de una app conocida (mismos colores, forma similar), pueden rechazarlo por riesgo de confusión.

5. targetSdk desactualizado

Google exige que las nuevas apps usen un targetSdk reciente. En 2025, el mínimo es API 34 (Android 14). Si publicás con targetSdk 28, el build es rechazado automáticamente.

# Si te rechazan:
# 1. Leer el email de rechazo completo (tienen un link a la política específica)
# 2. Corregir SOLO lo que dicen — no hagas cambios no relacionados
# 3. En "Enviar para revisión" podés agregar una nota explicando qué corregiste
# 4. El proceso de re-revisión tarda igual que la primera vez

Después de publicar — lo que no termina

Publicar es el comienzo, no el final. Las cosas que tenés que monitorear activamente:

Android Vitals en Play Console

Play Console tiene una sección "Android Vitals" que muestra métricas de calidad: crash rate, ANR rate, startup time, consumo de batería. Google usa estas métricas para rankear tu app en búsquedas. Si tu crash rate supera ciertos umbrales, tu app puede ser penalizada en el ranking.

Reseñas y rating

Las primeras reseñas son las más importantes — establecen la percepción de la app. Respondé todas las reseñas negativas con amabilidad y con información concreta de qué vas a corregir. Los usuarios que ven que respondés son más propensos a cambiar su calificación después de una actualización.

Actualizaciones de política de Google

Google actualiza sus políticas regularmente. Te llegan emails a la cuenta de Play Console cuando hay cambios que afectan tu app. Si ignorás esos emails y no cumplís con los nuevos requisitos en el plazo indicado, tu app puede ser removida.

# Cosas a actualizar regularmente:
# - targetSdk: Google da plazos para actualizar (generalmente 1 año)
# - Política de privacidad: si cambiás qué datos recopilás
# - Clasificación de contenido: si agregás features con contenido sensible
# - Declaración de acceso a datos: si cambiás el uso de datos del usuario