Flutter o nativo para la app de tu empresa: lo que aprendimos con Tajo y Pax

La respuesta corta (sí, empieza por «depende»)

• Fluttersi necesitas Android y iPhone (o móvil más un panel web), el presupuesto es de pyme y la app es sobre todo formularios, listas, fotos, mapas y sincronización. Que es lo que son casi todas las apps de empresa.
• Nativosi la app vive pegada al hardware o al sistema: audio en tiempo real, Bluetooth con aparatos propios, widgets y extensiones del sistema por todas partes, o funciones que Apple y Google estrenan este año y quieres el primer día.
• Nativo en una sola plataformasi todos tus usuarios usan Android (pasa en muchas plantillas con móvil de empresa). Una base de código nativa también es una sola base.

Dos bases de código son dos de todo

El coste de lo nativo no está en escribir la app, está en mantenerla. Cada cambio se hace dos veces, se prueba dos veces y se puede romper de dos maneras distintas. Cada fallo hay que reproducirlo en dos proyectos. Y las dos apps tienden a separarse: un botón que en Android hace una cosa y en iPhone otra, porque se arregló un lado y el otro se quedó para la semana que viene.

En Flutter la lógica de negocio se escribe una vez y los tests también. En Tajo, el cálculo de jornadas, la cola de fichajes sin cobertura y las reglas de quién ve qué viven en un solo sitio, con sus tests, y los usa tanto la app de los operarios como el panel de escritorio de RRHH. Si esa lógica estuviera duplicada en Kotlin, Swift y JavaScript, cada regla de control horario habría que demostrarla tres veces.

Rendimiento: el cuello de botella casi nunca es el framework

Flutter no usa los botones y listas del sistema: dibuja cada píxel con su propio motor, Impeller, que según la documentación oficial es el único en iOS y el de serie en Android 10 y posteriores. Por eso una app Flutter se ve igual en todos los móviles, para bien y para mal: si quieres que en iPhone parezca exactamente una app de Apple, te toca trabajarlo.

¿Va más lenta? No vamos a darte una cifra, porque las comparativas que circulan miden casos de laboratorio. Lo que sí podemos decir es dónde se nos ha ido el tiempo en apps de empresa: consultas a la base de datos mal planteadas, imágenes sin comprimir, llamadas de red en el arranque. Nada de eso lo arregla cambiar de lenguaje. Por eso, en Tajo, las fotos y vídeos de los partes se comprimen en el móvil antes de subir: en obra la red es lo que manda.

GPS, cámara, NFC y segundo plano: las reglas son de Android, no de Flutter

Flutter accede al hardware mediante plugins: paquetes que por dentro llevan su código Kotlin y Swift y lo exponen en Dart. Para GPS, cámara, micrófono, notificaciones o biometría hay plugins muy usados y mantenidos. Para NFC existe, por ejemplo, nfc_manager, de un editor independiente y no del equipo de Flutter: antes de depender de un plugin así, mira quién lo mantiene y cuándo se actualizó por última vez.

Lo que mucha gente no espera: las restricciones del sistema operativo te alcanzan igual. En Tajo, la ruta de un desplazamiento entre obras se graba mientras dura, también con la pantalla bloqueada. Desde Android 14, eso exige un servicio en primer plano de tipo ubicación, con su permiso FOREGROUND_SERVICE_LOCATION declarado y una notificación visible. Lo resolvimos sin escribir Kotlin, con la configuración de primer plano del plugin geolocator, pero tuvimos que conocer la regla de Android al detalle. El framework no te la quita.

Cuándo hay que bajar a Kotlin (y cuánto)

Cuando no hay plugin, Flutter permite hablar con el código nativo por un canal de plataforma (MethodChannel): Dart pide, Kotlin o Swift contesta. Nuestro recuento real, para que veas la escala:

• Tajo: cero líneas de Kotlin propias. La actividad principal de Android está vacía; GPS, cámara, dictado por voz (con el reconocimiento del propio Android, sin mandar el audio fuera) y notificación de desplazamiento salen de plugins.
• Pax: unas 120 líneas de Kotlin. El widget del proverbio en la pantalla de inicio, porque los widgets de inicio se construyen con las herramientas de cada plataforma, no con Flutter. Y, mientras existió la llamada de voz con el mentor, un canal para pasar el audio al altavoz, porque el modo de grabación para conversación lo mandaba por defecto al auricular.

Esa llamada de voz con el mentor, conectada a Gemini Live, fue lo más duro que hemos hecho con Flutter. La sesión se cortaba al segundo: la conexión en tiempo real no enviaba la identidad de la app Android y Google la rechazaba por la restricción de la clave. Después el micrófono grababa sin cancelación de eco y el modelo se oía a sí mismo por el altavoz. Ninguno de los dos problemas se habría evitado escribiendo la app en Kotlin: eran de la plataforma y de la configuración.

Web y escritorio con el mismo código: sí, con letra pequeña

El panel de escritorio de RRHH de Tajo es la misma app Flutter compilada para web, con pantallas pensadas para ventana ancha. Para un cliente así es una ventaja enorme: la exportación del registro horario, los modelos de datos y las reglas de permisos son el mismo código que en el móvil.

La letra pequeña: hay código que compila sin avisar para web y falla al ejecutarse, como el acceso a ficheros del móvil o los plugins de cámara. En Tajo lo resolvimos con implementaciones separadas para web y para móvil detrás de la misma función. Y algunos errores de maquetación solo aparecían en el navegador, como una pantalla en blanco que el análisis estático no veía y solo se descubrió con la consola abierta.

React Native, Kotlin Multiplatform y PWA

• React Native: de Meta, se escribe en JavaScript o TypeScript con React y pinta con los componentes nativos de cada sistema. Tiene sentido si tu equipo ya vive en React. El razonamiento sobre plugins y reglas del sistema es el mismo que con Flutter.
• Kotlin Multiplatform: comparte la lógica en Kotlin y, con Compose Multiplatform, también la interfaz; según JetBrains, ambos son estables en Android e iOS. Buena opción si ya tienes una app Android en Kotlin y quieres llevarla a iPhone sin reescribirla.
• PWA (web instalable): sin tiendas y con una sola base. Pero el acceso a hardware y a segundo plano es más limitado, y en iPhone las notificaciones push solo llegaron con iOS 16.4 y únicamente si el usuario añade la web a la pantalla de inicio. Para una herramienta interna sencilla puede bastar; para fichar con GPS en obra, no la elegiríamos.