Publicar en App Store y Google Play una app hecha con Bolt
Cómo llevar una app móvil hecha con Bolt.new y Expo a TestFlight, App Store y Google Play: cuentas, builds con EAS, reglas de las tiendas y rechazos comunes.
Read in English →
Bolt.new arma las apps móviles con Expo, pero no las sube a las tiendas por ti. Descargas el código, usas la herramienta de línea de comandos de Expo (EAS) para generar builds firmados y los subes: en iOS a TestFlight y después a la revisión del App Store; en Android a una pista de pruebas de Google Play Console y después a producción. Necesitas una membresía del Apple Developer Program, una cuenta de desarrollador de Google Play y una cuenta gratuita de Expo.
En esta guía verás qué cuentas y ajustes decidir antes del primer build, los comandos para cada tienda, las reglas que cambiaron en 2026 y los motivos más frecuentes de rechazo en el primer envío.
¿Qué necesito antes del primer build?
- Un proyecto que nació como app móvil. La documentación de Bolt lo dice claro: escribe "mobile app" en tu primer prompt, porque los proyectos creados para la web no pasan fácilmente a móvil después.
- La membresía del Apple Developer Program (US$99 al año) para publicar en iOS.
- Una cuenta de desarrollador de Google Play (un registro único de US$25) para publicar en Android.
- Una cuenta de Expo, además de Node.js LTS y Git en tu computadora.
- Una URL con tu política de privacidad y un contacto de soporte. Las dos tiendas los piden.
¿Qué ajustes no se pueden cambiar después?
Decídelos antes del primer build, porque cambiarlos luego es un dolor de cabeza o directamente imposible.
| Ajuste | Dónde | Por qué importa |
|---|---|---|
slug | app.json | La guía de Expo en Bolt avisa que no se puede cambiar tras el primer build |
Identificador de iOS (ios.bundleIdentifier) | app.json | Identifica la app en App Store Connect; queda fijo una vez creada |
Nombre de paquete de Android (android.package) | app.json | Identifica la app en Google Play; no cambia después de la primera subida |
Nombre de la app (name) | app.json | Se puede cambiar, pero el nombre de la ficha en la tienda se define aparte |
Usa un identificador con estilo de dominio invertido que controles, como com.tuempresa.tuapp.
¿Cómo genero y envío los builds con EAS?
1. Prepara el proyecto en tu computadora
Descarga el proyecto desde Bolt (o clónalo desde GitHub) y ejecuta:
npm install -g eas-cli
eas login
npm install
npx expo-doctor
eas init
eas build:configureexpo-doctor detecta problemas de dependencias y configuración antes de que gastes un build en ellos. eas build:configure crea el archivo eas.json con los perfiles de compilación.
2. iOS: primero TestFlight, después el App Store
eas build --platform ios --auto-submitEAS compila la app, se encarga de los certificados de firma (puede crearlos por ti), crea la ficha en App Store Connect y manda el build a TestFlight. Instálalo desde la invitación de TestFlight y pruébalo en un teléfono real. Cuando esté listo, completa la ficha en App Store Connect (capturas, descripción, respuestas de privacidad, clasificación por edad) y envíala a revisión.
Un cambio de 2026: desde el 28 de abril de 2026, Apple solo acepta builds hechos con Xcode 26 o posterior y el SDK de iOS 26. Según el anuncio de Expo, el SDK 54 y los siguientes ya compilan con una imagen de Xcode 26 por defecto. Si tu proyecto de Bolt está en un SDK de Expo más viejo, la subida se rechaza antes de llegar a revisión, así que actualiza el SDK primero.
3. Android: una pista de pruebas y después producción
eas build --platform androidDescarga el archivo .aab desde el enlace que muestra EAS. En Google Play Console, crea la app, entra a Testing > Internal testing, crea una versión, sube el archivo y agrega testers por correo.
Dos reglas de Google sorprenden a quien empieza:
- Las cuentas personales creadas después del 13 de noviembre de 2023 tienen que hacer una prueba cerrada con al menos 12 testers durante 14 días seguidos antes de pedir acceso a producción. Las cuentas de organización están exentas. Consigue testers con tiempo.
- Nivel de API objetivo. Desde el 31 de agosto de 2026, las apps nuevas y las actualizaciones deben apuntar a Android 16 (nivel de API 36). Los SDK de Expo recientes lo configuran solos; uno viejo quizá no.
eas submit --platform android puede subir los builds por ti cuando configuras una clave de cuenta de servicio de Google. Para la primera versión, subirla a mano en Play Console es más sencillo.
¿Por qué rechazan el primer envío?
Estos son los problemas de revisión que más se repiten en apps generadas con herramientas de IA:
- El revisor no puede entrar. Si la app pide cuenta, deja un usuario de prueba que funcione en las notas para la revisión.
- No se puede borrar la cuenta desde la app. Las App Review Guidelines de Apple exigen que, si la app permite crear una cuenta, también permita eliminarla desde dentro.
- Compras digitales fuera del sistema de la tienda. Vender contenido digital o suscripciones dentro de una app de iOS, por regla general, tiene que pasar por la compra dentro de la app. La documentación de Bolt sugiere RevenueCat para esto. Los productos físicos y los servicios del mundo real pueden cobrarse con un proveedor como Stripe.
- Contenido de relleno y botones que no hacen nada. Lorem ipsum, pantallas de demo y pestañas de "próximamente" se leen como app sin terminar.
- Un simple envoltorio de una web. La regla de funcionalidad mínima de Apple rechaza apps que no aportan casi nada más que el sitio móvil.
- Se cierra al abrir, muchas veces por una variable de entorno que falta. En Expo, los valores que la app lee en tiempo de ejecución deben empezar con
EXPO_PUBLIC_y, como todo lo que va en el frontend, cualquiera que desarme la app puede verlos. Los secretos se quedan en el servidor. Lo explicamos en variables de entorno en Bolt.
¿Cómo publico actualizaciones?
Haz el cambio en Bolt, descarga o trae el código nuevo y vuelve a compilar y enviar:
eas build --platform ios --auto-submit
eas build --platform androidCada subida a la tienda necesita un número de build mayor. Con "autoIncrement": true en el perfil de producción de eas.json, EAS lo resuelve solo. Expo ofrece además actualizaciones por aire (EAS Update) para cambios que solo tocan JavaScript, dentro de las reglas de cada tienda; lo que agregue código nativo necesita un build nuevo.
¿Y si Expo Go no abre el proyecto desde Bolt?
Al probar en el teléfono, Expo Go puede decirte que iniciaste sesión en el celular pero no en Expo CLI, y el login desde la terminal de Bolt puede quedarse colgado, porque esa terminal corre en el navegador, no en tu computadora. La solución que documenta Bolt es crear un token de acceso personal en expo.dev, guardarlo como secreto con el nombre EXPO_TOKEN en el proyecto y volver a correr el comando de login.
Respuestas rápidas
¿Bolt publica en el App Store con un clic? No. La publicación de un clic de Bolt es para la web. Los builds para las tiendas pasan por EAS y por tus propias cuentas de desarrollador.
¿Necesito una Mac? No para los builds en la nube de EAS. Sí necesitas la cuenta de Apple y entrar a App Store Connect desde el navegador.
¿Cuánto tarda la revisión? Varía. Calcula al menos unos días para el primer envío de iOS, más los 14 días de prueba cerrada en una cuenta personal nueva de Google.
¿Puedo probar sin pagar las cuentas de desarrollador? Sí, con Expo Go en tu propio teléfono. Las cuentas pagas solo hacen falta para distribuir por las tiendas.
¿Quieres ayuda para pasar la revisión?
Nuestro servicio para publicar tu app en App Store cubre builds, fichas de tienda y respuestas a rechazos, y el de desarrollo de apps móviles sigue donde Bolt se queda corto. Si primero hay que arreglar la app, mira arreglar apps de Bolt o cuéntanos dónde te trabaste. Antes de enviar, nuestra guía para probar tu app con usuarios beta te ayuda a sacarle provecho a esos primeros testers.
