El proceso de desarrollo de apps Flutter: cómo llevamos una app de la idea a la App Store

Resumen. El proceso de desarrollo de una app Flutter transcurre en siete fases: descubrimiento y acotación, diseño UX/UI, arquitectura y cimientos, desarrollo iterativo, QA y pruebas, publicación y mantenimiento posterior al lanzamiento. Lo que las une es que son bucles de realimentación, no una cascada: el diseño empieza antes de que termine el descubrimiento, el QA corre junto al desarrollo en vez de después, y cada dos semanas recibes algo instalable en tu móvil en lugar de un informe de estado. La única regla que no doblamos: los invariantes van antes que el código de las funcionalidades. El modelo de estado, el tema, la taxonomía de errores, el pipeline de CI y la estrategia de tests se deciden en la semana uno, porque cada pantalla construida después o los sigue o se pelea con ellos. Un desarrollo típico son 2-3 meses para un MVP y 3-5 meses para un producto completo, y el lanzamiento es la mitad del proceso, no el final.

Los pasos del desarrollo Flutter de un vistazo

Siete fases, en el orden en que empiezan. Este es todo el ciclo de vida del desarrollo Flutter en una pantalla.

Esas duraciones son rangos y se solapan: el calendario es más corto que la suma de las filas. Para ver adónde van realmente las semanas en un proyecto real, mira el artículo complementario: cuánto se tarda en construir una app en Flutter. Para lo que cuesta cada fase, mira Cuánto cuesta desarrollar una app en Flutter en 2026.

Estructuralmente, este es el mismo proceso de desarrollo móvil que sigue cualquier equipo competente: las fases no son un invento de Flutter. Lo que cambia Flutter es la economía dentro de ellas: una base de código para la que diseñar, una que testear, una que publicar, y una capa de interfaz que vive en código y no en una hoja de estilos. Ese último detalle es la razón por la que las fases de diseño y arquitectura pesan aquí más de lo que pesarían en otro sitio.

1. Descubrimiento y acotación

El descubrimiento es la fase en la que una idea se convierte en una lista concreta y ordenada de cosas que construir. No es un taller con pósits. Es un lead y un diseñador interrogando la app hasta que cada pantalla tiene una razón para existir.

De ahí salen tres cosas:

• Un backlog, ordenado. No «gestión de usuarios», sino «iniciar sesión con Apple, iniciar sesión con correo, restablecer contraseña, eliminar cuenta». Las partidas vagas son donde mueren las estimaciones.
• Una lista de recortes. Las funcionalidades que no están en la versión uno, escritas y acordadas. El artefacto más valioso del proceso, y al que más se resisten los clientes.
• Un presupuesto de alcance cerrado y un calendario, derivados del backlog y no de una intuición sobre «una app como esta».

Aquí es donde se fijan de verdad los presupuestos y los plazos, y por eso un descubrimiento apresurado es la forma más cara de ahorrar una semana. Cuando describes «un registro de entrenamientos sencillo» y te devolvemos un backlog de 40 pantallas, ese hueco no es colchón: el onboarding, la autenticación, los ajustes, la eliminación de cuenta, los pagos, el push y el offline siempre estuvieron en la app que describiste. El desglose de costes cubre cómo el alcance se acumula hasta dar una cifra.

Dónde se rompe: un descubrimiento con alguien que no puede decidir. Si cada respuesta vuelve a un comité, el descubrimiento se estira de una semana a cuatro y la estimación se construye sobre arena.

2. Diseño UX/UI

El diseño UX/UI es la fase en la que se define el lenguaje visual y de interacción de la app. Empieza por el sistema, no por las pantallas.

El primer entregable es un sistema de diseño: una paleta con variantes clara y oscura, una escala tipográfica, una escala de espaciado, estados de componente (por defecto, pulsado, deshabilitado, cargando, error) y el vocabulario de interacción: cómo muestra esta app la carga, cómo muestra una lista vacía, cómo confirma una acción destructiva. Las pantallas se diseñan después contra ese sistema.

Ese orden no es preferencia estética: es velocidad de construcción. Una app Flutter renderiza cada píxel desde código Dart, y un sistema de diseño maduro se corresponde casi uno a uno con ThemeData; conectado una vez, cada pantalla posterior se ensambla con componentes que ya existen. Sin él obtienes lo que describimos en por qué los agentes de IA se atascan con Flutter: cuarenta pantallas que funcionan cada una y no suman una app, colores incrustados en cada punto de uso y un cambio de marca que cuesta un diff de varios cientos de archivos.

También diseñamos para las restricciones que rompen después las maquetaciones de Flutter: cadenas largas en el segundo idioma, escala de texto al 200 %, móviles pequeños a 320 pt. Detectar eso en Figma cuesta minutos; detectarlo en QA cuesta un rediseño. Lo que sacas de la fase es un sistema de diseño más un prototipo navegable, antes de que exista una línea de código de funcionalidades.

Dónde se rompe: el diseño por ciclos de revisión. Tres rondas de «¿podemos ver una opción más?» en la pantalla de inicio retrasan todas las fases posteriores, porque los ingenieros no pueden construir contra un objetivo móvil.

3. Arquitectura y cimientos

La arquitectura es la fase en la que se toman las decisiones de las que dependerá cada pantalla posterior, antes de que exista ninguna pantalla. En la práctica, eso significa que pasamos una o dos semanas construyendo una app que no hace nada.

Esa quincena decide los seis meses siguientes. Lo que queda cerrado:

• Gestión de estado. Una elección, aplicada en todas partes. Clases de estado selladas, para que las combinaciones ilegales —cargando y error a la vez— sean irrepresentables en lugar de meramente improbables.
• Estructura de carpetas y fronteras entre módulos. Dónde vive una funcionalidad y qué puede importar.
• Una taxonomía de errores. Modos de fallo con nombre —red, autenticación caducada, validación, pago rechazado, conflicto— en lugar de un único Algo ha salido mal que hace irreproducible todo bug.
• CI/CD. Pipeline en verde el primer día: flutter analyze con los lints promovidos a errores, flutter test, un artefacto de build por commit y Fastlane conectado a TestFlight y al canal interno de Play.
• Estrategia de pruebas. Qué capas llevan tests de widget, qué pantallas llevan goldens y cuál es el presupuesto de tiempo de fotograma.

Los llamamos los invariantes, y van primero porque no pueden añadirse después de forma barata. «Sigue el patrón existente» es una instrucción barata de dar a una persona o a un agente, pero solo cuando existe un patrón al que señalar. En un repositorio sin ninguno, cada cual inventa el suyo, y el resultado es la arqueología que nos pagan por auditar dos años después. La fase termina con un esqueleto funcionando, un pipeline en verde y registros de decisión breves para las elecciones que un futuro ingeniero volvería a discutir.

4. Desarrollo iterativo

El desarrollo iterativo es la fase en la que las funcionalidades se construyen y se entregan en incrementos pequeños y demostrables, en lugar de en un bloque al final. El flujo de trabajo de Flutter aquí va en rebanadas verticales de funcionalidad: una funcionalidad construida de principio a fin —interfaz, estado, integración con la API, gestión de errores, tests— en vez de «todas las pantallas» seguido de «toda la fontanería». Una rebanada que puedes abrir en un móvil te dice algo cierto. Una carpeta de pantallas sin conectar, no.

La cadencia es un incremento demostrable cada una o dos semanas, en tu dispositivo vía TestFlight o el canal interno de Play. No una captura, no un vídeo: la app, en tu móvil, que puedes pasarle a un compañero.

La revisión de código va sobre decisiones, no líneas. ¿Es este el mismo modelo de estado que el resto de la app? ¿Está estilizado desde el tema? ¿Este valor se deriva una vez, o por tercera vez? ¿Sobrevive esta cadena al ruso? Los agentes escriben buena parte del código y nuestros ingenieros son dueños de esas decisiones, que es cómo construimos: la revisión línea a línea del código generado no escala; la revisión a nivel de decisión sí.

El diseño y el QA siguen corriendo en paralelo, y el trabajo de backend también, que es por lo que un sistema como la capa de datos de mercado en tiempo real de ExtraETF se construye y se prueba bajo carga mientras el cliente Flutter todavía está ensamblando pantallas contra un mock.

Dónde se rompe: los sprints silenciosos. Si pasan dos semanas sin que abras una build, el bucle está roto y te enteras del malentendido un mes tarde.

5. QA y pruebas

El QA es la capa que corre desde la primera rebanada de funcionalidad hasta la última, no una fase atornillada al final: comprobaciones automáticas en CI en cada commit, más una pasada de endurecimiento antes de publicar.

Qué corre en CI en cada commit:

• Tests de widget para el comportamiento: el botón se deshabilita mientras se envía, el error se limpia al reescribir, la lista pagina en el desplazamiento correcto.
• Golden tests para la apariencia, el tipo de test de mayor palanca en Flutter, porque un golden convierte «¿este rediseño ha roto el estado vacío a 320 pt en modo oscuro con el texto al 200 %?» en una comprobación que corre en segundos en vez de en una pregunta que nadie hace.
• Tests de integración para los flujos que pierden dinero cuando se rompen: registro, checkout, pago.
• Un test de regresión por cada bug arreglado, para que no pueda volver.

Lo que una máquina no puede hacer, lo hace una persona sobre hardware real: la app al 200 % de escala de texto, en modo oscuro, en ambos idiomas, en un móvil Android pequeño y antiguo, con la red limitada y después cortada a mitad de una petición. Diez minutos de eso encuentran toda una categoría de defectos que ninguna comprobación estática reportará jamás.

Y mantenemos un presupuesto de fotograma: 16,6 ms a 60 fps, comprobado en builds de perfil. Una lista que da tirones después de que alguien añada una sombra y un Opacity dentro del constructor del elemento es una regresión que ningún test unitario detecta y que todos los usuarios sienten.

6. Publicación

La publicación es la fase en la que la app pasa por el envío a las tiendas, la revisión y el despliegue. Son 1-2 semanas de trabajo que la mayoría de los calendarios finge que son una tarde.

Materiales y metadatos de tienda: capturas en todos los tamaños requeridos, descripciones, palabras clave, etiquetas de privacidad, declaraciones de seguridad de datos. La eliminación de cuenta tiene que existir dentro de la app; ambas tiendas lo exigen.

Realidades de la revisión. La revisión de Apple suele ser de 24-48 horas, pero «suele» no es «garantizado», y las categorías de rechazo son predecibles: falta la eliminación de cuenta, un muro de login sin credenciales de demostración, una declaración de privacidad incompleta, pagos que esquivan la compra dentro de la app. Para quien publique varias apps de marca, la directriz 4.2.6 es una disciplina propia: cubrimos qué pasa realmente la revisión a escala de flota. La revisión de Google suele ser más rápida, pero una cuenta de desarrollador nueva puede quedarse en revisión extendida durante días.

Despliegue escalonado. Publicamos al 10 % en Google Play y vigilamos la tasa sin fallos antes de ampliar; el lanzamiento por fases de la App Store hace lo mismo. Una build mala detectada al 10 % es una tarde mala. Esa misma build al 100 % es una semana mala.

Automatización. Fastlane compila, firma y sube a ambas tiendas, incluidos los montajes multieditor donde cada marca se publica bajo su propia cuenta. La publicación manual es donde alguien teclea mal un número de versión a las once de la noche.

7. Post-lanzamiento y mantenimiento

El mantenimiento posterior al lanzamiento es la fase en la que la app se encuentra con usuarios reales y sigue cambiando. El lanzamiento es su comienzo, no el final del proyecto.

El uso real saca a la luz de inmediato lo que ningún test podía: la capa de Android de un fabricante que rompe las notificaciones push, la actualización del sistema que retira una API, el fallo en un dispositivo que no tenías. Así que el proceso continúa:

• Monitorización: informes de fallos, trazas de rendimiento y analítica sobre los flujos que importan, vigilados cada hora las primeras 48 horas y semanalmente después.
• Iteración: el backlog que recortaste en el descubrimiento, repriorizado contra lo que la gente hace de verdad.
• Mantenimiento: releases anuales del sistema, actualizaciones de SDK, cambios de política de las tiendas, rotación de certificados y de claves de API. Flutter y sus plugins se mueven; una app sin tocar durante un año no es estable, está caducando.

Presupuesta para el producto, no para el proyecto. Una app que se publica y luego no recibe nada va por el camino lento de vuelta a una reescritura.

Cómo lo mantenemos en rumbo

Los procesos no fallan de forma dramática. Resbalan unos días cada vez. Cuatro cosas evitan casi todo, y cada una tiene un modo de fallo conocido.

Alcance cerrado y por escrito. La lista de recortes del descubrimiento es un contrato con el calendario; las ideas nuevas van a la lista de la v2 y lo decimos en voz alta. Se rompe cuando nadie defiende la lista: cada «añadido diminuto» es genuinamente diminuto, y el vigésimo es un mes.

Una cadencia decidida con quien decide. Una persona que pueda aprobar una pantalla el día que la ve, una llamada semanal, una build que instalar. Se rompe cuando las decisiones pasan por un comité. En un desarrollo de seis semanas, una semana de latencia de decisión es un desvío del 20 % antes de que ningún ingeniero haya hecho nada mal.

Invariantes fijados de entrada. La razón por la que nuestro tercer mes cuesta más o menos lo que costó el primero. Se rompe cuando una fecha límite tienta a todo el mundo a saltarse la semana uno y empezar por las pantallas.

Bucles cortos de realimentación. Builds instalables cada una o dos semanas, QA en CI, una demo que de verdad abres. Se rompe cuando el cliente se queda callado: el bucle solo funciona si hay alguien al otro lado.

Y la honesta: nuestras estimaciones se equivocan en una dirección. Las integraciones son donde más fallan. Todo SDK de terceros parece una tarde en la presentación y se convierte en dos semanas de depuración sobre casos límite en Android 10. Metemos holgura para eso en vez de fingir que no existe, y cuando una fase va a desbordarse te enteras esa semana, no en la fecha de entrega.

Preguntas frecuentes

Acotemos tu desarrollo

Así se construyen las apps Flutter cuando alguien está llevando de verdad el proceso. Si estás evaluando agencias, el proceso es el producto: capturas te enseña cualquiera. Lo que decide si tu app sale a tiempo es si hay una máquina real detrás: una lista de recortes que alguien defiende, invariantes fijados en la semana uno, una build en tu móvil cada quincena y tests que corren antes de que mire una persona.

• Reserva una llamada de descubrimiento y pasaremos tu idea por el paso uno: habla con nosotros. Recibes un backlog ordenado, una lista de recortes y un presupuesto de alcance cerrado, no un rango lo bastante ancho como para esconderse en él.
• Mira la oferta: equipo, stack y niveles de precio en la página de desarrollo de apps con Flutter.
• ¿Ya tienes un desarrollo? Si alguien llevó mal este proceso, una auditoría de código IA te dice cuánto cuesta arreglarlo en el sitio, casi siempre menos que la reescritura que te están presupuestando.

Cuéntanos qué estás construyendo y dónde estás atascado, y te diremos qué fases serán fáciles y cuáles dolerán.

Dima es lead Flutter developer en Nerdy Production, una agencia Flutter primero que lleva apps del descubrimiento a la App Store en fintech, retail y productos de IA.