Flutter — Por qué, librerías, arquitectura y CI/CD

TL;DR

Dribba es la única agencia española en el directorio oficial de consultores Flutter de Google y trabajamos con Flutter en producción desde 2017. Para apps con UI propia, iOS + Android paritarios y MVPs entre 6 y 14 semanas, es nuestra apuesta por defecto. NO recomendamos Flutter cuando hay audio profesional en tiempo real, AR/VR avanzado, juegos 3D pesados o integraciones muy bajas con CarPlay/Android Auto. Nuestro stack estándar: Riverpod (estado), GoRouter (navegación), Dio (HTTP), freezed (modelado), get_it (DI), flutter_test + mocktail (testing). Arquitectura Clean Architecture organizada por features, CI/CD en Codemagic o Fastlane, observabilidad con Sentry.

Por qué Flutter

La apuesta por defecto en 2026 — con caveats explícitos

Trabajamos en Flutter desde 2017, cuando todavía era alpha y la mayoría de las agencias ni sabían que existía. Esa antigüedad nos ahorra (y te ahorra) el coste de aprendizaje: cuando Google lanza una nueva versión, cuando hay un breaking change crítico, cuando aparece una vulnerabilidad en un paquete clave, lo hemos visto antes.

En 2026 Flutter es la apuesta sensata para el 90% de las apps que llegan a una agencia: una sola base de código, paridad iOS/Android desde el primer commit, hot reload < 1 s, engine de render (Impeller) maduro y un ecosistema con backing real de Google. Para startups con time-to-market corto y mantenimiento sostenible, es difícil que React Native o nativo justifiquen su coste adicional.

El otro 10% de casos sí pide otra tecnología y lo decimos en la primera llamada. No vendemos Flutter como si fuera universal: vendemos la decisión correcta.

Cuándo NO usar Flutter

Casos donde recomendamos otra tecnología

Si tu producto encaja en alguno de los siguientes, te orientamos hacia nativo (Swift/Kotlin) o, en casos puntuales, React Native.

Audio profesional en tiempo real (DAW móvil, monitorización pro de instrumentos): la latencia y el control fino del audio engine se gestionan mejor en nativo.
AR/VR avanzado con ARKit o ARCore complejos (oclusión, tracking de cuerpo, anclas persistentes): los plugins Flutter llegan con semanas de retraso respecto al SDK oficial.
Juegos 3D con motores propios o Unity/Unreal: Flutter no es un game engine.
Integraciones con CarPlay / Android Auto con UI custom: la API oficial sigue siendo nativa-first y Flutter expone solo subconjunto.
Equipos cliente con dependencia fuerte de Swift / Kotlin senior in-house que van a recoger el código en menos de 12 meses: si tu equipo no va a aprender Dart, mejor nativo.

Stack estándar Dribba

Librerías que llevamos a producción por defecto

Esta es nuestra plantilla inicial cuando arranca un proyecto Flutter. Si hay una razón concreta para sustituir una pieza, lo discutimos en el discovery.

Riverpod 2 (estado): Gestión de estado predecible, sin BuildContext frágil, con providers tipados y testing trivial. Sustituye a Provider y a Bloc para la mayoría de casos. Reactividad explícita.
GoRouter (navegación): Router declarativo basado en URLs, alineado con la API de Navigator 2. Deep links, route guards, transitions custom. Lo preferimos sobre auto_route por estabilidad y backing oficial.
Dio (HTTP): Cliente HTTP con interceptores (auth, retry, logging), cancelación, timeouts configurables. Más maduro que el package http vanilla para producción.
freezed + json_serializable: Modelado de datos inmutable con copyWith, ==/hashCode generados, sealed classes para state machines. Reduce ~40% del boilerplate típico.
get_it + injectable: Inyección de dependencias para mantener Clean Architecture limpia. Service locator simple, sin la magia de Provider para casos donde el ciclo de vida es de aplicación, no de widget.
Sentry (observability): Crash reporting con stack traces simbolicados, release tracking, performance monitoring. Mejor cobertura que Firebase Crashlytics para apps que no están del todo en GCP.
flutter_test + mocktail: Tests unitarios para domain/data, widget tests para UI crítica, integration tests para flows end-to-end. mocktail evita las limitaciones de mockito con null safety.
very_good_analysis (linter): Reglas de análisis estrictas que detectan smells antes de pasar a review. CI falla si hay warnings — política inegociable en producción.

Arquitectura por defecto

Clean Architecture organizada por features

No usamos MVC ni MVVM por defecto. Cada feature es una vertical aislada con sus propias capas, lo que hace que se pueda añadir, quitar o sustituir sin tocar el resto.

Presentation

Widgets + ViewModels (Riverpod providers). Sin lógica de negocio. Recibe estado, dispara intents. Lo único que cambia cuando el diseñador iteró sobre UX.

Domain

Entities, use cases y repositories abstractos. Cero dependencias de Flutter. Lo que sobreviviría a un rewrite a otra UI framework. Aquí vive la lógica de negocio.

Data

Implementaciones concretas: REST con Dio, Firebase, GraphQL, caches locales con Hive/Drift. Aquí se cambia el back-end sin tocar UI ni casos de uso.

Core / shared

Utilidades cross-feature, theme, design tokens, components compartidos. Cuidado con engordarlo: lo que solo usa una feature, vive en esa feature.

CI/CD

Pipeline estándar de release

Desde el sprint 0 montamos automatización completa. Cero scripts manuales en producción.

Push a rama feature → CI (GitHub Actions): lint + tests unitarios + build APK debug.
Pull request a main → CI completo: tests + integration tests + análisis estático + dependencia check.
Merge a main → Codemagic o Fastlane: build firmada para iOS y Android, distribución a TestFlight y Google Play Internal Testing.
Tag de release → Codemagic: submit a App Store Connect y Google Play Console con release notes desde changelog.
Post-release: Sentry monitoriza primeras 72 h, alerta si crash rate > umbral, rollback automático configurado en Codemagic.

Testing strategy

Qué se testea, dónde, con qué coverage objetivo

No perseguimos coverage por el coverage. Apuntamos a cobertura accionable: domain y data al 80%+, UI crítica con widget tests, flows clave con integration tests.

Unit tests · Domain & Data: Use cases, repositories, mappers, validators. Cobertura objetivo: 80%+. Son los más baratos de mantener y los que más bugs cazan.
Widget tests · UI crítica: Pantallas con lógica condicional, formularios, estados de carga/error. No testeamos cada widget — solo los que tienen estado o branching real.
Integration tests · Flows clave: Onboarding, checkout, signup, recuperación de contraseña. Corren en CI con dispositivo virtual o en Firebase Test Lab.
Golden tests: Solo para design system shared y para componentes con regression visual repetida. Coste de mantenimiento alto si se abusa.

Una decisión técnica que solemos defender

Riverpod sobre Bloc por defecto. Bloc fuerza más boilerplate y, en 2026, la inmensa mayoría de los proyectos no necesitan la separación rígida de events/states que Bloc impone. Riverpod da el mismo control con menos código y mejor testabilidad. Si el equipo cliente ya domina Bloc, lo respetamos — pero no es nuestra opción por defecto.

Preguntas frecuentes

Lo que nos preguntan sobre este tema

Flutter en producción se usa por equipos muy diversos: BMW (apps de coche conectado), Google Ads, Toyota, eBay Motors, Alibaba, Square, ByteDance, Reflectly, y la mayoría de las apps de fintech, healthtech y retail lanzadas en los últimos 3 años en España y LatAm. El ecosistema enterprise creció especialmente entre 2023 y 2026 a medida que Impeller (el engine moderno) estabilizó la performance.

Clean Architecture organizada por features, no por capas. Cada feature contiene sus capas presentation/domain/data internamente. Esto permite añadir o quitar features sin tocar el resto del código y facilita que equipos paralelos trabajen sin pisarse. Para apps simples (MVP de 5–10 pantallas) reducimos la rigidez de la separación; para apps con dominio rico, mantenemos las tres capas estrictas.

Tres razones objetivas: (1) Menos boilerplate — Riverpod prescinde de la dualidad event/state que Bloc impone y reduce ~30–40% del código de estado. (2) Mejor testabilidad — los providers se pueden overrides en tests sin mocks complejos. (3) Tipado más explícito gracias a la API generada de Riverpod 2. Bloc sigue siendo válido si el equipo cliente ya lo usa o si el patrón event-driven encaja con el dominio.

Sí, sin reservas para apps de UI. Impeller (el engine nuevo de render) está estable desde 2024 en iOS y Android. Las releases de Flutter son trimestrales y conservadoras: breaking changes documentados con antelación y herramientas de migración (dart fix). La mayoría de los bugs críticos en 2026 vienen de plugins de terceros mal mantenidos, no del core.

Flutter Web compila tu código Dart a JavaScript y dibuja con Canvas o con Skia (vía CanvasKit). Funciona para internal tools, dashboards y prototipos rápidos donde quieres compartir UI con la app móvil. NO lo recomendamos para landing pages, blogs ni productos donde el SEO o el first paint importan: para eso Next.js o SvelteKit son la decisión correcta.

Sí. Flutter expone Method Channels y Pigeon (mejor para tipos seguros) para invocar código nativo desde Dart. Lo usamos cuando un plugin oficial no cubre una API específica (Bluetooth LE avanzado, sensores propietarios, integración con SDK comercial de terceros). El coste: cada integración nativa duplica el work iOS+Android, así que solo se hace cuando hay justificación clara.

El rango típico va del 40% al 70% del coste de un rewrite desde cero, dependiendo de cuánto del dominio se pueda extraer limpiamente. La migración por feature (un módulo a la vez) suele ser más segura que big-bang. Las apps con dominio bien aislado se migran más rápido; las que tienen lógica de negocio mezclada en ViewControllers requieren refactor previo.

FlutterRiverpodGoRouterfreezedCodemagicFastlaneClean ArchitectureDartSentryFlutter Partner Google

Flutter en producción: lo que llevamos al mercado en 2026