Publicar tu app en la App Store y en Google Play
La app que ya publicaste en la web se convierte en una app nativa de verdad, con push y cámara, y llega a las tiendas bajo tu propia cuenta de desarrollador. La configuración lleva unos 10 minutos; la primera publicación, de 1 a 2 días, por la revisión de las tiendas.
Qué es tuyo y qué es nuestro
La app sale bajo tu cuenta de desarrollador, nunca bajo la nuestra. No es un detalle burocrático: la ficha de la tienda, las valoraciones, las descargas y el dinero de las compras son tuyos, y siguen siendo tuyos si algún día te vas de la plataforma.
Lo que hacemos: empaquetamos la app publicada en una cáscara nativa, generamos el icono y la pantalla de inicio, compilamos en la nube (no hace falta un Mac) y enviamos a la tienda con la credencial que conectaste. Lo que es tuyo: la cuenta de desarrollador, crear la app en la consola de la tienda y responder a la revisión.
La app nativa ejecuta la versión publicada de tu proyecto. Si todavía no publicaste en la web, la pestaña lo pide antes, porque no hay nada que empaquetar.
Antes de empezar
- el proyecto publicado en la web (el botón Publicar);
- el plan Builder o superior;
- una cuenta de desarrollador en la tienda donde quieras salir: Google Play (pago único de US$ 25) o el Apple Developer Program (US$ 99 al año), pagados directamente a la tienda;
- una hora de paciencia con la consola de la tienda la primera vez.
Puedes hacer Android ahora e iOS después. Las dos plataformas avanzan por separado de principio a fin.
Dónde está
La pestaña Aplicación, en la columna de iconos del editor. Es la última, con el icono de móvil.
Los cinco pasos de la configuración
El asistente guarda solo a cada paso, así que puedes salir a la mitad y volver después.
| Paso | Qué decides |
|---|---|
| Tiendas | dónde sale la app: App Store, Google Play o las dos |
| Marca | icono, pantalla de inicio y el identificador de la app |
| Funciones | cámara, fotos, ubicación, biometría, push y compartir |
| Cuentas | las credenciales de Apple y Google (la guía Conectar tus cuentas de Apple y Google detalla cada campo) |
| Revisar | comprobar todo y publicar |
Marca
El icono tiene que ser un PNG cuadrado de 1024×1024. Sin él generamos uno con la inicial de la app sobre el color de tu marca. Apple rechaza los iconos con fondo transparente: envíalo con el fondo relleno y sin esquinas redondeadas, porque el sistema las redondea solo.
La pantalla de inicio funciona mejor como un PNG con la marca centrada y fondo transparente, ya que el color que elijas rellena el resto de la pantalla. Una foto a pantalla completa se recorta de forma distinta en cada aparato.
El identificador de la app
Es la dirección única de la app en las tiendas, con el formato com.tuempresa.tuapp. Sugerimos uno a partir del
nombre del proyecto y puedes cambiarlo por tu dominio al revés.
No cambia después de la primera publicación. Cambiarlo más tarde no renombra la app: crea una app nueva en la tienda, y tu base de usuarios, valoraciones y descargas se quedan en la antigua. Compruébalo antes de publicar.
En Google Play hay una trampa más: la app tiene que existir en la consola con exactamente ese identificador antes
del envío. La API de Google no crea la app, así que si el paquete no está allí el envío falla con Package not found. La pantalla muestra el identificador con un botón de copiar justamente para que lo pegues en la Play Console
sin equivocarte en un carácter.
Funciones
Activa lo que la app usa de verdad. Las tiendas esperan que una app nativa use funciones nativas: una app que es solo el sitio dentro de una cáscara suele ser rechazada, con más frecuencia por Apple.
Activar push aquí es lo que hace que la app pida permiso de notificación. En Android, entregar la notificación además exige los dos archivos de Firebase, en el paso Cuentas.
Build de prueba: instálala antes de enviar
Antes de mandar nada a una tienda, usa el Build de prueba. Genera una app que se instala directamente en el aparato, sin pasar por la tienda, y tarda de 10 a 30 minutos.
Los dos lados se comportan distinto cuando el build termina:
- Android: sale un APK y el botón Instalar te entrega el archivo. Se instala en el aparato al momento;
- iOS: el paquete se envía a App Store Connect y aparece en TestFlight cuando Apple lo procesa. No hay archivo para descargar e instalar en el iPhone directamente.
En ambos casos: una app que nunca abriste en un aparato no debería ir a revisión.
Publicar
En el paso Revisar el botón es Publicar en las tiendas. A partir de ahí la pantalla muestra tres estados, por plataforma:
| Estado | Qué significa |
|---|---|
| Compilando | generando la app nativa en la nube. De 10 a 30 minutos |
| Enviando a la tienda | el paquete está listo y se está subiendo. La tienda todavía no respondió |
| Enviado a la tienda | la tienda aceptó el paquete. La revisión empieza ahora |
La diferencia entre los dos últimos es la que más confunde, y es real: un paquete puede estar listo y aun así ser rechazado en el envío (identificador equivocado, permiso faltante). Por eso "Enviado a la tienda" solo aparece cuando la tienda confirma que lo recibió, no cuando termina el build.
Después de eso, quien informa es la consola de la tienda. La revisión ocurre dentro de Apple y de Google, y no tenemos forma de seguirla. Tarda de unas horas a 2 días, y más en la primera versión de una app.
Cuenta personal nueva en Google Play: los 12 testers
Si tu cuenta de Google Play es personal y se creó después del 13 de noviembre de 2023, Google exige, antes de abrir producción, una prueba cerrada con al menos 12 testers inscritos de forma continua durante 14 días. Es por app, no por cuenta.
No es un requisito de Fabapp y no hay forma de saltarlo desde aquí: el envío funciona, la app queda disponible en el canal de prueba, y la producción solo se abre después de que pidas acceso y Google lo apruebe (hasta 7 días). Las cuentas de organización y las personales creadas antes de esa fecha están exentas.
Planifícalo desde el principio si tu cuenta es nueva: son 14 días de calendario que no se pueden acelerar.
Los plazos de las tiendas que son nuestros, no tuyos
Las tiendas exigen que la app se compile con herramientas recientes, y esos plazos son responsabilidad nuestra: mantenemos la cáscara nativa al día y tú no tienes que hacer nada.
Para que sepas que existen: Google Play exige que las apps nuevas y las actualizaciones apunten a Android 16 (API 36) desde el 31 de agosto de 2026, y Apple exige que los envíos a App Store Connect se compilen con el SDK de iOS 26 o superior desde el 28 de abril de 2026.
Cuando algo falla
| Síntoma | Casi siempre |
|---|---|
Package not found en el envío de Android |
la app no existe en la Play Console con ese identificador, o el identificador es distinto |
| el envío de Android se rechaza por permisos | la cuenta de servicio existe pero nunca recibió permiso para publicar en la Play Console |
| el build de iOS falla al final, hablando de un certificado | la clave de App Store Connect no tiene el rol Admin |
| la app de iOS no aparece en TestFlight | Apple todavía está procesando el paquete. Suele tardar unos minutos |
| el push funciona en el iPhone y no en Android | faltan los archivos de Firebase en el paso Cuentas |
El log completo de cada build está en la propia pestaña, en Ver el log completo. Es lo primero que hay que mirar, y su mensaje de error suele ser literal.