¿Puedo crear una app móvil con IA sin saber programar?

Puedes crear una sencilla: un agente de código puede escribir las pantallas, los datos y el inicio de sesión con React Native y Expo. Aun así tendrás que leer errores, probar en un móvil y encargarte tú de los pasos de las tiendas, lo que requiere nociones básicas de terminal más que experiencia programando.

¿Es mejor Flutter o React Native para crear una app con IA?

Si estás empezando, React Native con Expo es más fácil: Expo Go muestra cada cambio al instante en tu móvil, y JavaScript y TypeScript son lo que más han visto los agentes de código. Flutter también es una buena opción, sobre todo si ya conoces Dart.

¿Puedo publicar en la App Store una app hecha con IA?

Sí. Apple y Google juzgan la app, no quién escribió el código. Necesitas una membresía de pago del Apple Developer Program, una política de privacidad, capturas de pantalla y una app que funcione lo bastante bien como para pasar la revisión.

¿Cuál es el backend más fácil para una app móvil?

Un backend alojado como Supabase o Firebase es mucho más fácil que escribir tu propio servidor. Ambos te dan autenticación, base de datos y almacenamiento de archivos de serie; lo importante es no dejar abiertas las reglas de seguridad (RLS en Supabase, reglas de seguridad en Firebase).

¿Por qué los agentes de IA sufren con los errores de compilación nativa?

Porque esos errores vienen del entorno, no del código: Xcode, el SDK de Android, CocoaPods, versiones de Gradle y certificados de firma. El agente no puede ver tu máquina, así que dale la salida completa del error y usa una compilación en la nube como EAS Build para mantener el entorno fijo.

Crear una app móvil con IA: de Expo a las tiendas

La forma más rápida de crear una app móvil con IA es hacer que un agente de código monte un proyecto de React Native con Expo, probar cada cambio en tu propio móvil con Expo Go y usar un backend alojado como Supabase o Firebase. El agente escribe las pantallas, la capa de datos y el inicio de sesión; tú pruebas en el dispositivo, le devuelves los errores y te encargas de los pasos de las tiendas. Publicar sigue requiriendo cuentas de desarrollador de Apple y Google y pasar sus procesos de revisión.

Este artículo recorre todo el camino desde una carpeta vacía hasta las tiendas: qué stack elijo y por qué, el primer prompt que le doy al agente, cómo pruebo en un móvil, autenticación y notificaciones, publicación y dónde tropiezan más los agentes.

Primero, fija las expectativas

Hay una diferencia real entre hacer vibe coding de un sitio web y de una app móvil. En la web, si el código se ejecuta, has terminado. En móvil hay una capa de plataforma encima del código: herramientas de compilación, certificados de firma, permisos, reglas de las tiendas. El agente maneja con soltura casi todo el código; la parte de plataforma necesita tus ojos y tus manos.

La buena noticia: si eliges bien las herramientas, no tocarás la mayor parte de esa capa de plataforma durante las primeras semanas.

Qué stack: Expo, Flutter o nativo

Hay tres caminos principales.

Opción	Lenguaje	Por qué elegirla	Ojo con
React Native + Expo	TypeScript	Pruebas instantáneas en el dispositivo con Expo Go, compilaciones en la nube, el lenguaje que mejor conocen los agentes	Las librerías nativas personalizadas no funcionan en Expo Go; necesitas una development build
Flutter	Dart	Una sola base de código, aspecto coherente, buenas herramientas	Menos ejemplos de Dart en los que se apoyen los agentes; probar en el dispositivo requiere una toolchain local
Nativo (Swift / Kotlin)	Swift, Kotlin	Acceso total a la plataforma, el mejor rendimiento	Dos apps separadas, hacen falta Xcode y Android Studio

Para quien empieza mi respuesta es clara: React Native + Expo. El motivo tiene menos que ver con méritos técnicos y más con la velocidad del feedback. El agente cambia algo y lo ves en tu móvil segundos después. Cuanto más corto es ese ciclo, mejor funciona el vibe coding.

Flutter es una buena elección si conoces Dart o tu equipo ya lo usa. Lo nativo solo tiene sentido cuando tienes una razón concreta, como procesamiento de cámara, gráficos pesados o integración profunda con la plataforma.

Paso 1: Preparación

Lo que necesitas:

Node.js (una versión LTS) y un gestor de paquetes
Un agente de código: Claude Code, Codex, Gemini CLI u otro agente de código
Expo Go en tu móvil, desde la App Store o Google Play
Git, para poder deshacer cada paso que dé el agente

Crea tú el proyecto. Los agentes que generan el esqueleto desde cero a veces recurren a plantillas obsoletas:

npx create-expo-app@latest habits
cd habits
git init && git add -A && git commit -m "initial scaffold"
npx expo start

En la terminal aparece un código QR. Escanéalo con la cámara en iPhone o desde dentro de Expo Go en Android, y la app se abre en tu móvil. El ordenador y el móvil deben estar en la misma red Wi‑Fi. Si la red lo impide, prueba npx expo start --tunnel.

Paso 2: El primer prompt

El primer prompt marca cada decisión que tome el agente después. Si dejas huecos, los rellena con sus propias preferencias. Yo escribo algo así:

This is an Expo (React Native, TypeScript) project. We're building a
simple habit tracker.

Screens:
1. Today: list of habits, each with a "done" button
2. Add: create a habit with a name and a daily goal
3. History: calendar view of the last 30 days

Rules:
- Use expo-router for navigation and follow the existing app/ folder.
- Keep data on the device for now (AsyncStorage). Backend comes later.
- Add packages with npx expo install, not npm install.
- Don't add native packages that don't run in Expo Go; ask first.
- Run npx tsc --noEmit after each step and fix the errors.
- When done, list the files you changed.

Dos líneas importan más que el resto. npx expo install elige la versión del paquete que coincide con tu SDK de Expo, y los agentes se la saltan continuamente. La regla de «nada de paquetes que no funcionen en Expo Go» te mantiene fuera de las compilaciones nativas hasta que de verdad las necesites.

Paso 3: Prueba en el móvil e itera

Mientras npx expo start se está ejecutando, la app se recarga en tu móvil conforme el agente edita archivos. El ciclo:

Pruébalo en el móvil y anota lo que está mal.
Díselo al agente con precisión: «En la pantalla Add el teclado tapa el botón de guardar, en iPhone».
Si aparece la pantalla roja de error, copia el texto literalmente al agente. Una captura de pantalla también sirve; la mayoría de los agentes pueden leer imágenes.
Haz commit de cada paso que funcione.

Prueba tanto en iOS como en Android. El mismo código se comporta de forma distinta: márgenes de área segura, manejo del teclado, el botón de atrás, las sombras. Si solo tienes un móvil, usa un emulador de Android o (en Mac) el simulador de iOS para la otra plataforma.

Paso 4: Backend con Supabase o Firebase

Cuando quieras datos compartidos entre dispositivos y cuentas de usuario, necesitas un backend. No escribas tu propio servidor; elige uno alojado:

Supabase: construido sobre PostgreSQL. Base de datos, autenticación, almacenamiento de archivos y actualizaciones en tiempo real. Encaja bien si conoces SQL o quieres aprenderlo.
Firebase: la plataforma de Google. Base de datos de documentos Firestore, autenticación, mensajería. Muy integrado con el ecosistema móvil.

Haz que el agente lo construya capa a capa, no todo de golpe:

We're moving to Supabase. For now, only do this:
1. Write a SQL file under supabase/migrations that creates habits and
   completions tables. Every row has a user_id.
2. Enable Row Level Security on both tables so a user can only read
   and write their own rows.
3. Don't change the app code yet. Show me the SQL; I'll apply it.

No te saltes la parte de RLS. La clave de Supabase que va dentro de una app móvil es pública por diseño; lo que protege tus datos son las reglas de la base de datos, no que esa clave sea secreta. En Firebase, las reglas de seguridad cumplen el mismo papel.

Paso 5: Autenticación

El inicio de sesión con correo es el más sencillo; Supabase y Firebase lo ofrecen los dos. Iniciar sesión con Google y con Apple requiere más configuración: URIs de redirección, un esquema de app y el registro en la consola de cada plataforma.

Algo que conviene saber: según las directrices de la App Store, si tu app ofrece un inicio de sesión social de terceros, Apple puede esperar también Sign in with Apple o una alternativa equivalente que respete la privacidad, con algunas excepciones. Comprueba las reglas vigentes antes de enviarla.

Así es como pido la autenticación:

Add email + password sign-in with Supabase Auth.
- If there's no session, redirect to the sign-in screen.
- Store the session with expo-secure-store.
- Put a sign-out button on the Settings screen.
- Error messages should be clear and in plain English.
Don't add Google or Apple sign-in yet.

Paso 6: Notificaciones push

Las notificaciones push consumen más tiempo que cualquier otra cosa en móvil. En Expo empiezas con expo-notifications:

npx expo install expo-notifications expo-device

Lo que debes saber:

Las notificaciones locales («recuérdame cada tarde a las 21:00») no necesitan servidor y son, con diferencia, lo más fácil. Para un rastreador de hábitos suelen ser todo lo que necesitas.
El push remoto implica obtener un token de push, guardarlo en tu servidor y enviar desde allí. En iOS esto requiere una cuenta de Apple Developer y la capacidad de push.
Prueba el comportamiento de las notificaciones en un dispositivo real. El soporte de notificaciones en el simulador y en Expo Go puede ser limitado y cambia con el tiempo.

Pide primero al agente notificaciones locales, comprueba que funcionan y luego pasa al push remoto.

Paso 7: Compilaciones y tiendas

Expo Go sirve para desarrollar; las tiendas reciben un binario real de la app. El servicio en la nube de Expo, EAS, lo compila por ti:

npm install -g eas-cli
eas login
eas build:configure
eas build --platform android
eas build --platform ios

La gran ventaja de las compilaciones en la nube es no tener que configurar tú mismo Xcode y el SDK de Android. Incluso puedes generar la compilación de iOS sin un Mac.

Apple:

Una membresía anual de pago del Apple Developer Program.
Un registro de la app en App Store Connect con capturas de pantalla, una descripción, la URL de una política de privacidad y la declaración de datos App Privacy.
Distribuye por TestFlight primero a ti y a unos pocos testers, y después envía a revisión.
Los rechazos son normales. Motivos habituales: cuelgues, falta de texto de privacidad, apps «envoltorio de sitio web» sin sustancia y apps que te dejan crear una cuenta pero no eliminarla.

Google:

Un registro único de pago en Google Play Console, más verificación de identidad.
Una ficha de la tienda, el cuestionario de clasificación de contenido y el formulario Data safety.
Las cuentas personales de desarrollador nuevas pueden tener que hacer una prueba cerrada con un número determinado de testers durante un periodo determinado antes de pasar a producción; comprueba la regla vigente en la consola.

eas submit facilita el envío de compilaciones a ambas tiendas, pero los formularios de las tiendas los rellenas tú. Léelos en lugar de delegarlos en el agente; declarar qué datos recoge tu app es responsabilidad tuya.

Dónde sufren los agentes

Esta es la lista de sitios donde más tiempo he perdido haciendo vibe coding de apps móviles.

Errores de compilación nativa

Gradle, CocoaPods, versiones de Xcode, niveles del SDK de Android. Estos errores son largos, ruidosos y específicos del entorno. El agente no puede ver el Xcode de tu máquina; adivina. Lo que ayuda:

Pega la salida completa del error, no las primeras líneas. La causa real suele estar cerca del final o enterrada en medio.
Usa EAS Build siempre que puedas; el entorno se mantiene fijo.
No dejes que el agente edite a mano las carpetas ios/ y android/. En Expo suelen generarse a partir de la configuración, así que los cambios duraderos van en app.json o en un config plugin.

Firma y certificados

Certificados, perfiles de aprovisionamiento e identificadores de bundle en iOS; un keystore en Android. Los agentes pueden dar instrucciones seguras de sí mismas pero equivocadas aquí. Dejar que EAS gestione las credenciales es el camino más suave. Si pierdes tu clave de subida de Android, publicar actualizaciones de la misma app se convierte en un auténtico quebradero de cabeza, así que haz una copia de seguridad.

Desajustes de versión

El agente usa la API de un paquete de cuando fue entrenado; tu proyecto puede tener otra versión. npx expo install --check lista los paquetes que no coinciden. Decirle al agente «comprueba primero la versión en package.json y luego escribe según la documentación de esa versión» ayuda.

Probar en una sola plataforma

El agente escribe un layout que funciona en iOS y se desborda en Android. Comprueba cada funcionalidad en ambas.

Pedirlo todo a la vez

«Añade autenticación, notificaciones y pagos» deja las tres cosas a medias. Una funcionalidad cada vez, con un commit entre medias.

La seguridad importa aún más en móvil

Todo lo que pones en una app móvil acaba en el dispositivo del usuario, donde se puede desempaquetar y leer. Por eso:

Nunca pongas secretos en el bundle de la app. En Expo, las variables de entorno que empiezan por EXPO_PUBLIC_ se incrustan en el bundle, lo que las hace públicas. La clave service_role de Supabase, la clave secreta de un proveedor de pagos o una clave de API de IA nunca deben ir en la app; pertenecen al lado del servidor, por ejemplo en una edge function.
Guarda los secretos en un archivo .env y comprueba que .env está en .gitignore.
No pegues claves de API en el chat. Dile al agente qué variable de entorno leer, no la clave en sí.
Prueba las reglas de tu base de datos. Inicia sesión con una segunda cuenta y comprueba si puedes leer los datos de la primera.
Lee los comandos que ejecuta el agente, sobre todo eas, git push, borrados y comandos de base de datos, antes de aprobarlos.

Hacerlo con AgentVera

Puedes hacer todo lo anterior en una terminal normal. En proyectos móviles me gusta ejecutar varios agentes en paralelo, y lo hago en AgentVera:

Agentes separados en worktrees separados. Por ejemplo, Claude Code trabaja en el esquema de Supabase y las edge functions en un git worktree mientras Codex construye pantallas en otro. El panel de Git muestra los cambios de cada rama.
Una terminal en la cuadrícula. npx expo start se queda abierto en un panel para que veas la salida de Metro junto a los agentes; para eso sirve el panel de editor y terminal.
Revisión antes de fusionar. La revisión de código automática hace que un segundo modelo compruebe cada turno del agente; aun así, deberías leer tú mismo el diff.
La base de datos. Añade la conexión Postgres de Supabase al gestor de bases de datos para revisar las tablas y filas que creó el agente.
Seguimiento de tokens. Los logs de compilación largos inflan el contexto rápidamente; el uso de tokens se ve por panel.

AgentVera no compila para tu móvil ni envía a las tiendas; esa parte sigue en manos de Expo y de las consolas de las tiendas.

Lista de comprobación rápida

Proyecto de Expo creado por ti, primer commit en git
El primer prompt enumera pantallas, reglas y el requisito de npx expo install
Cada funcionalidad probada en un móvil, en ambas plataformas
RLS en Supabase o reglas de seguridad en Firebase activadas y probadas
Ninguna clave secreta en el bundle de la app
Keystore de Android con copia de seguridad
Política de privacidad y declaraciones de datos de las tiendas listas

Para terminar

Crear una app móvil con IA es hoy un objetivo realista, pero no termina en «escríbeme una app». Empieza con Expo, mira cada cambio en tu móvil con Expo Go, usa un backend alojado, añade funcionalidades de una en una y hazte cargo tú de los pasos de plataforma: firma, formularios de las tiendas, revisión. Para comprobar lo que escribió el agente, mira revisión de código con IA; para ejecutar agentes en paralelo, mira git worktrees para agentes en paralelo.