Por qué una ficha en Google Play importa para un SaaS
Una pestaña del navegador compite con todas las demás pestañas abiertas. Una app instalada tiene su propio icono en la pantalla de inicio, a la vista del usuario cada vez que desbloquea el teléfono. Para un SaaS que se abre a diario, la diferencia no es cosmética: se nota en la retención.
Icono en la pantalla de inicio
Un recordatorio diario de tu producto, donde una pestaña acaba olvidada
Notificaciones push
Recuperar usuarios inactivos, avisar antes de que termine una prueba, anunciar novedades
Visibilidad en la tienda
La búsqueda de Google Play trae usuarios que nunca han visto tu sitio web
Señal de confianza
«Disponible en Google Play» da seguridad a los compradores que dudan
Sin reescritura
Tu stack web es la app: actualizas el sitio y la app lo sigue
Lo que Play Store realmente verifica
La revisión automatizada de Google Play para paquetes de web apps verifica cuatro cosas:
- Nivel de API objetivo — debe ser 36 (Android 16) para todas las apps y actualizaciones nuevas desde el 31 de agosto de 2026.
- Funcionalidad mínima — según las reglas de Google sobre spam y funcionalidad mínima, la app debe hacer algo útil. Una página estática de una pantalla falla; una app multipantalla, un dashboard SaaS o una plataforma de contenido pasa.
- Formulario de seguridad de datos — debes declarar qué datos recopila tu app. Requerido para todas las apps.
- Firma válida — el .aab debe firmarse con un keystore. El mismo keystore debe usarse para cada actualización futura de ese nombre de paquete.
TWA vs Capacitor: elegir el build correcto para tu web app
| Criterio | TWA | Capacitor |
|---|---|---|
| Manifest PWA requerido | Sí (icono ≥192px, HTTPS); service worker recomendado, no obligatorio | No — cualquier URL HTTPS funciona |
| Tamaño de la app | Muy ligera | Más pesada: incluye una envoltura nativa |
| Renderizado | Navegador Chrome (comparte cookies/caché) | WebView del sistema (aislado) |
| Notificaciones push | Web Push de tu sitio (service worker) | Firebase nativo (más fiable) |
| Plugins nativos | No | Cámara, biometría, atajos |
| API level 36 | ✓ (via Bubblewrap) | ✓ (via Capacitor CLI) |
| Soporte offline | Requiere service worker en tu app | Puede inyectar SW o usar caché nativo |
Paso a paso: de la URL de la web app a Play Store
1. Ejecutar una verificación PWA
Pega tu URL en un verificador PWA gratuito. Te muestra tu puntuación de manifest, si tienes service worker, y si TWA o Capacitor es la ruta correcta. Tarda 10 segundos.
2. Configurar la identidad de tu app
Establecer un nombre de paquete en formato de dominio inverso (com.tuempresa.nombreapp). Es permanente — identifica tu app en Play Store para siempre.
3. Construir el .aab firmado
Un build de pago de SaasToStore genera el Android App Bundle firmado. Tu keystore se crea en el primer build de pago, se guarda cifrado y se reutiliza en cada actualización; su contraseña te llega una vez por correo. El build apunta automáticamente a API level 36 (Android 16) y tarda unos minutos.
4. Crear una cuenta de Play Console
Registrarse en play.google.com/console y pagar la tarifa única de 25$ para desarrolladores. La verificación de identidad suele tardar 1–2 días.
5. Crear una nueva app y subir
En Play Console, crear nueva app → pista de producción → subir el .aab. Completar las secciones requeridas: contenido de la app, audiencia objetivo, declaración de seguridad de datos, cuestionario de clasificación de contenido, URL de política de privacidad. Luego enviar para revisión.
Preparar la ficha y evitar los rechazos
Antes de enviarla, la ficha de Google Play tiene que estar completa. Esto es lo que pide. SaasToStore puede generar por ti el icono, el gráfico destacado, las capturas y un primer borrador de las descripciones.
Archivo de la app
Un .aab firmado
Icono
PNG de 512×512 px
Gráfico destacado (feature graphic)
1024×500 px
Capturas de pantalla
Al menos 2, de teléfono
Descripción breve
Hasta 80 caracteres
Descripción completa
Hasta 4.000 caracteres
Política de privacidad
Una URL pública
Los cuatro errores que más a menudo frenan una primera publicación:
Perder el keystore
Sin la clave original no se puede publicar una actualización con el mismo nombre de paquete. SaasToStore crea la clave de cada app en el primer build de pago, la guarda cifrada y la reutiliza en cada actualización; su contraseña te llega una vez por correo.
Enviar sin política de privacidad
Publica una política de privacidad e indica su URL antes de enviar la app. SaasToStore puede generarte una.
Un icono del tamaño equivocado o con transparencia
Prepara un PNG cuadrado de 512×512 px con fondo sólido. Google Play redondea las esquinas por su cuenta.
Un sitio sin HTTPS
Activa HTTPS en tu hosting antes de lanzar el build: sin HTTPS no funciona ningún wrapper.
Lo que cuesta publicar
Del lado de Google, el registro de desarrollador del paso 4 cuesta 25$ una sola vez y sirve para todas las apps que publiques desde esa cuenta. El otro coste es fabricar el bundle firmado. A mano, las herramientas son gratuitas: la CLI Bubblewrap de Google para una TWA, la CLI de Capacitor para una envoltura nativa. Lo pagas en tiempo: instalar y mantener el SDK de Android y Java, depurar los builds que fallan y guardar una clave de firma que nunca puedes perder. Un builder alojado se encarga de todo eso y guarda la clave para cada actualización.
Con SaasToStore, el build de prueba gratuito es un APK con el logo de SaasToStore, para ver la app en tu propio teléfono. El .aab que subes a Google Play viene con un build de pago: consulta los precios.
Lo específico de un SaaS: inicio de sesión y notificaciones push
Inicio de sesión: casi nunca hay que cambiar nada
Tu autenticación actual (Supabase, Auth0, Clerk, tus propias sesiones) sigue funcionando en la app. Correo y contraseña o códigos de un solo uso se comportan como en tu sitio; los magic links también, una vez que los deep links los llevan a la app. En una TWA, la app comparte las cookies de Chrome: un usuario que ya inició sesión en Chrome en ese teléfono suele tenerla iniciada también en la app. Un build nativo Capacitor tiene su propia sesión: el usuario inicia sesión una vez en la app. La excepción es Google: rechaza su inicio de sesión dentro de una WebView integrada, así que la app nativa abre «Iniciar sesión con Google» en el navegador del sistema y luego devuelve al usuario a la app. Esa vuelta requiere autorizar una dirección en tu proveedor de autenticación.
Notificaciones push para la retención
El push es la principal palanca de retención que una app de tienda le da a un SaaS. Los mensajes que mejor funcionan:
- — La prueba termina en 3 días, con un enlace para pasar al plan de pago
- — Nueva actividad en algo que el usuario sigue: un comentario, una mención, una actualización
- — Un resumen semanal, o un hito de uso alcanzado
- — Una nueva función, enviada a los usuarios activos
- — Un recordatorio tras 7 días sin visitas
En el build nativo, las notificaciones salen de la propia app: las notificaciones del navegador de tu sitio no pasan a la app.
Más allá de Google Play
La misma sesión de build que produce tu Google Play AAB también puede generar un Windows .msi, macOS .dmg y Linux .AppImage — publicados en Microsoft Store, Snap Store, Flathub y GitHub Releases.
En Android, la misma app llega también a Amazon Appstore y a Samsung Galaxy Store, y la misma URL da una app de iPhone para la App Store. ¿Tu sitio está hecho con una herramienta no-code? Consulta las guías de Lovable, Bubble y Webflow.
Verifica si tu web app está lista para las tiendas
Verificación PWA gratuita — puntuación de manifest, estado del service worker, recomendación de ruta de build. 10 segundos.
Verificar mi app →