Desarrollo de apps con Flutter: móvil, web y escritorio

Flutter gana cuando la paridad de interfaz multiplataforma con precisión de píxel importa más que parecer 100 % nativo, cuando quiere un equipo que entregue iOS y Android (y web/escritorio) desde un único repositorio y cuando su sistema de diseño es a medida y no el de la plataforma. React Native gana cuando su equipo ya vive en TypeScript y su app son sobre todo pantallas sobre APIs. Swift/Kotlin nativo gana en AR/VR, integración profunda con el sistema operativo y apps con expectativas de UX específicas de la plataforma (p. ej., apps de consumo premium solo para iOS). Kotlin Multiplatform gana cuando quiere compartir lógica de negocio pero mantener una interfaz nativa — ideal para equipos nativos existentes que añaden uso compartido de código sin comprometerse con un único framework de interfaz. Hemos entregado con los cuatro y se lo diremos con honestidad durante el descubrimiento.

Flutter 3.27 estable con Dart 3.6 a fecha de 2026. Material 3 por defecto para marcas con inclinación hacia Android, Cupertino con widgets adaptables para las que se inclinan hacia iOS. Versiones mínimas admitidas: iOS 14 y Android API 24 (cubre más del 99 % de los dispositivos en los mercados de la UE y EE. UU.). Fijamos el SDK de Flutter por proyecto con fvm para que todos los colaboradores y el CI ejecuten exactamente la misma compilación. Revisiones trimestrales de actualización del SDK — en producción nunca dejamos una versión de Flutter más de dos versiones menores por detrás de la estable.

Sí. El backend usa por defecto regiones de la UE (AWS eu-central-1, GCP europe-west3, Supabase eu-central-1) con claves KMS en poder de la cuenta del cliente. Entregamos los App Store Privacy Manifests (obligatorios desde mayo de 2024) declarando cada API de motivo obligatorio (required-reason API) y cada recogida de datos de los SDK. La sección Play Data Safety se completa según el inventario real de SDK. Consentimiento del RGPD mediante UMP (Google) o un CMP a medida integrado con nuestro stack de analítica e informes de fallos. Solicitud ATT de Apple donde se necesite el IDFA. Identificadores anónimos por defecto, PII solo con opt-in.

Drift (SQLite) o Isar como almacén local, con nuestra propia capa de sincronización o PowerSync cuando el cliente quiere sincronización gestionada. La resolución de conflictos usa por defecto last-write-wins en registros simples y transformaciones operacionales o CRDT en datos colaborativos. Sincronización en segundo plano con WorkManager (Android) y BGTaskScheduler (iOS) con cadencia de 15 minutos y retroceso exponencial ante fallos. Hemos entregado una app de servicio de campo que sobrevivió a un hueco sin conexión de 27 días (buque en el mar) y sincronizó 14 GB de datos de inspección al reconectar sin un solo conflicto que requiriese resolución manual.

Sí, es un proyecto habitual. Paso 1: dejar en verde la suite de pruebas en la versión existente. Paso 2: completar la migración a null-safety (la mayoría de los equipos se quedaron al 80 %). Paso 3: actualización del SDK paso a paso 2.10 → 3.0 → 3.10 → 3.19 → 3.27 con pruebas en verde en cada paso. Paso 4: sustituir las API obsoletas (RaisedButton → ElevatedButton, AccessibilityFeatures, temas de BottomNavigationBar). Paso 5: introducir Riverpod 2 o Bloc 8 junto al Provider/setState existente y migrar por funcionalidad. Una app típica de 80k LOC lleva de 3 a 5 meses sin congelar funcionalidades.

Los proyectos de Flutter son de alcance cerrado y escalonados según la madurez del producto, todo incluido y presupuestados en USD. Un MVP cuesta desde $3,500 (4–8 semanas: una base de código Flutter, flujo principal, iOS y Android, release en tiendas); una app de producción, desde $5,800 (varias funcionalidades, integración con backend, persistencia offline, analítica); un producto completo, desde $9,200 (varios módulos, roles, integraciones externas, CI/CD, QA en dispositivos reales); y una app compleja, desde $11,500 (sincronización offline-first, plugins FFI nativos, pagos, escala, A/B). La cifra exacta depende del número de funcionalidades y superficies, la profundidad de la migración, los plugins FFI nativos y el alcance de cumplimiento. Usted ve el presupuesto desglosado tras una evaluación de alcance gratuita y lo aprueba antes de que se escriba una sola línea de código. NDA, DPA y cesión de la propiedad intelectual se firman antes del inicio, con jornada CET y solapamiento de 9:00–13:00 ET para clientes de EE. UU. Opciones de equipo dedicado y de ampliación de equipos bajo petición.

Flutter gana cuando se cumplen tres condiciones: (1) quiere paridad de interfaz con precisión de píxel entre iOS y Android sin concesiones de plataforma — Flutter renderiza con su propio motor gráfico Impeller, de modo que la interfaz es idéntica en todas las plataformas por construcción; (2) no puede permitirse dos equipos de ingeniería nativa separados con cadencias de release distintas; y (3) su sistema de diseño tiene una marca propia y no se apoya en las iOS Human Interface Guidelines ni en los valores por defecto de Material Design. React Native es la mejor opción cuando su equipo ya vive en TypeScript, su app son sobre todo pantallas finas sobre una API y la New Architecture se ha estabilizado lo suficiente para su conjunto de paquetes objetivo. Swift/Kotlin nativo gana en AR/VR, integraciones profundas a nivel de sistema operativo (CarPlay, SharePlay, apps centradas en watchOS) o productos en los que la UX específica de la plataforma es un diferenciador. Hemos entregado con las tres y le daremos una recomendación honesta en el descubrimiento en función de su equipo, su calendario y las restricciones de su producto — no del stack que prefiramos facturar.

Los Platform Channels son el mecanismo de Flutter para llamar desde Dart a código nativo en Swift (iOS) o Kotlin (Android). Hay tres formas: MethodChannel para llamadas puntuales (abrir la cámara, leer un valor de sensor), EventChannel para flujos de datos (actualizaciones de ubicación en vivo, lecturas de sensores de salud) y BasicMessageChannel para comunicación bidireccional continua. Para la generación de código con tipado seguro de la superficie de la API nativa usamos Pigeon, que genera código Dart, Swift y Kotlin coincidente a partir de un archivo de esquema — eliminando los errores de tipo en tiempo de ejecución y los fallos de serialización que aparecen cuando el lado Dart y el nativo se desalinean. Dart FFI (Foreign Function Interface) es una alternativa para bibliotecas C y C++ (runtimes de cifrado, motores de inferencia de ML, SDK de hardware) en las que se quiere sobrecarga nula y ningún viaje de ida y vuelta de paso de mensajes. Hemos escrito plugins de Platform Channels para HealthKit, Health Connect, Core NFC, el modo en segundo plano de Core Location, ARKit y varios periféricos BLE específicos de hardware. Los puentes nativos generados con Pigeon se prueban unitariamente tanto en el lado Dart como en el nativo, de modo que la desalineación de interfaces se detecta antes de llegar a TestFlight.

Sí. Flutter 3.x apunta a seis plataformas desde una única base de código: iOS, Android, web (tanto con renderizadores CanvasKit como HTML), macOS, Windows y Linux. Los destinos web y de escritorio han alcanzado madurez de producción para la mayoría de los casos de uso, aunque la profundidad de la integración nativa con el sistema operativo varía — el escritorio obtiene barras de menú, bandeja del sistema, multiventana y selector de archivos; la web tiene limitaciones de SEO (Flutter web renderiza en canvas, no en HTML semántico, por lo que necesita una estrategia de SEO aparte si importa la búsqueda orgánica). Para herramientas SaaS y productos B2B internos, la capacidad de Flutter de entregar una app móvil y un cliente de escritorio desde una única base de código resulta realmente atractiva: un sistema de diseño, un conjunto de lógica de negocio, un pipeline de release. Construimos diseños adaptables a la plataforma que cambian entre una barra de pestañas inferior en móvil y una NavigationRail o un cajón lateral en pantallas anchas, de modo que la app resulta adecuada en cada superficie sin mantener código de interfaz separado. Acotamos de forma explícita los destinos web y de escritorio en el descubrimiento — cada uno añade trabajo de diseño y QA que dimensionamos con honestidad.

Nuestra opción por defecto en proyectos nuevos es Riverpod 2 con generación de código (riverpod_generator y riverpod_annotation). Los providers generados por código están tipados con precisión, se pueden probar de forma aislada y evitan el boilerplate que hacía verboso a Riverpod 1. Usamos AsyncNotifier para el estado del servidor (carga, error, datos), Notifier para el estado local de la interfaz y modificadores family para providers parametrizados (p. ej., el estado de detalle por entidad). Bloc 8 (con hydrated_bloc para la persistencia) es nuestra preferencia cuando un equipo tiene experiencia previa con Bloc o cuando la pista de auditoría de transiciones explícitas de evento a estado importa para el cumplimiento — el registro de eventos es una especificación comprobable de las reglas de negocio. Provider y setState se mantienen para el estado local de widgets hoja donde Riverpod sería sobreingeniería. GetX no se usa en proyectos nuevos — su estado global implícito es incompatible con la arquitectura modular que construimos para facilitar las pruebas. En las migraciones introducimos Riverpod 2 o Bloc 8 junto al Provider/setState existente, migramos por funcionalidad en lugar de una reescritura de golpe y mantenemos la suite de pruebas en verde en cada paso.

El motor de renderizado Impeller de Flutter (por defecto desde Flutter 3.16 en iOS y Flutter 3.19 en Android) eliminó los tirones por compilación de shaders que hacían que el desplazamiento de Flutter 2.x se sintiera irregular en la primera ejecución. En dispositivos iOS con ProMotion (120 Hz) y dispositivos Android de alta frecuencia de refresco, las apps de Flutter construidas con Impeller alcanzan de forma constante 60 o 120 fps en cargas estándar de listas y animaciones — confirmado con los gráficos de Frames de Flutter DevTools e Instruments en el dispositivo. El arranque en frío es el área en la que Flutter aún va por detrás de lo nativo entre 200 y 400 ms en dispositivos Android de gama media porque la VM de Dart se inicializa al arrancar; lo abordamos con una pantalla de bienvenida nativa, un calentamiento de isolates en segundo plano y una carga diferida de componentes para empujar ese coste más allá del primer renderizado significativo. La sobrecarga de memoria es mayor que la de una app nativa ligera — el motor de Flutter añade aproximadamente 4 MB en iOS y 8–12 MB en Android — pero para la mayoría de las categorías de producto queda muy dentro de límites aceptables. Donde el rendimiento nativo puro es un requisito firme (AR en tiempo real, procesamiento de señal, sondeo de sensores de alta frecuencia), llamamos al código nativo mediante Platform Channels o Dart FFI en lugar de intentar hacerlo en Dart.

Flutter no puede llamar directamente desde Dart a las API específicas de la plataforma — esa es la respuesta honesta. Los Platform Channels (MethodChannel, EventChannel) permiten que una función Dart llame a un método de Swift (iOS) o a una función de Kotlin (Android) de forma síncrona o como flujo. Para la generación de código con tipado seguro usamos Pigeon, la herramienta de Google del equipo de Flutter, que genera las interfaces de Dart, Swift/Obj-C y Kotlin/Java a partir de un único archivo de esquema, eliminando los errores manuales de códec. En pub.dev, los paquetes bien mantenidos (health para HealthKit/Health Connect, geolocator para la ubicación, local_auth para la biometría) abstraen los puentes de Platform Channel habituales para que no tenga que escribirlos desde cero. Para SDK de nicho (protocolos BLE de dispositivos médicos, hardware a medida) escribimos un plugin propio y lo publicamos internamente.

Flutter web está listo para producción en paneles, herramientas internas e interfaces B2B con muchos datos en las que la base de usuarios está definida y es controlable. El renderizador canvaskit da una paridad de interfaz con precisión de píxel con el móvil, pero añade una descarga de WASM de ~2 MB en la primera visita, que mitigamos con carga diferida por puntos de división y una pantalla esqueleto. El SEO sigue siendo una limitación — Flutter web renderiza en Canvas, no en DOM, por lo que no es adecuado para sitios de contenido ni para páginas donde importa la búsqueda orgánica. Flutter de escritorio (macOS, Windows, Linux) se usa en producción para clientes de escritorio complementarios, herramientas internas e interfaces empresariales de gestión de licencias en las que el despliegue está controlado. Recomendamos Flutter de escritorio solo cuando la alternativa sea construir y mantener una app Electron o Tauri aparte desde otro base de código.

Los flavors de Flutter se asignan a los esquemas de Xcode (iOS) y a las variantes de compilación de Gradle (Android), lo que permite que una única base de código produzca compilaciones de dev, staging y producción con distintos bundle ID, iconos de app, nombres visibles, endpoints de API y feature flags. Usamos flutter_dotenv o el indicador --dart-define-from-file en tiempo de compilación para inyectar valores de entorno sin codificarlos a mano en el código Dart. Para los despliegues de marca blanca, cada cliente tiene su propio flavor con su propio paquete de assets, sus propias sobrescrituras de tokens de color y su propio proyecto de Firebase. El CI (GitHub Actions o GitLab CI) compila todos los flavors en cada merge a main, de modo que un cambio de feature flag en dev nunca llegue por accidente a producción sin pasar la misma suite de pruebas.

El uso compartido de código entre Flutter y un frontend web JS/TS se limita a la lógica de negocio que vive en una API de backend, no en la capa de cliente. Flutter Dart y React TypeScript son lenguajes y ecosistemas distintos — no es posible compartir directamente componentes de interfaz, hooks o utilidades. La arquitectura correcta es un backend API-first que consumen ambos clientes, con un esquema OpenAPI o GraphQL como contrato. Los tokens del sistema de diseño (colores, espaciados, tipografía) pueden compartirse mediante una herramienta de diseño como Figma y un script de exportación de tokens a medida, pero el código de los componentes no se comparte. Si la restricción principal es un uso compartido de código estrecho entre móvil y web, React Native con React Native Web o un monorepo Next.js + Expo es la recomendación técnicamente correcta. Trabajamos ambas prácticas y le diremos en el descubrimiento qué arquitectura encaja con la realidad de su equipo.

Flutter tiene un árbol semántico que se asigna a VoiceOver de iOS y TalkBack de Android mediante el widget Semantics y las propiedades semánticas automáticas de los widgets Material y Cupertino. Para el cumplimiento de WCAG 2.1 AA auditamos: tamaño mínimo del objetivo táctil (48×48 dp según las directrices de Material), ratios de contraste de color (4.5:1 para texto normal, 3:1 para texto grande) con el Colour Contrast Analyzer frente a los tokens del sistema de diseño, orden de foco y navegación por teclado para usuarios de teclado externo y cobertura de etiquetas semánticas en todos los elementos interactivos e imágenes. ExcludeSemantics oculta los elementos decorativos del árbol de accesibilidad. Ejecutamos el escáner de accesibilidad de Flutter y Accessibility Insights sobre la compilación final antes del envío y documentamos el nivel de cumplimiento en el traspaso del proyecto.