La pregunta más frecuente que me hacen sobre VantFi es por qué Flutter, sabiendo que el resto de mi stack es JavaScript/TypeScript. Tendría sentido elegir React Native para reutilizar conocimiento, librerías, y mental model. Pero no lo hice. Esta es la decisión y los criterios.
El criterio que más pesó: rendimiento percibido
VantFi es una app que la gente abre 5-10 veces al día por sesiones de 30 segundos. La velocidad percibida es todo. Si abrir la app, registrar un gasto y cerrarla toma más de 3 segundos, perdimos.
Flutter compila a código nativo (ARM en mobile), no usa puente de JavaScript. Eso significa que la animación de abrir un screen, transicionar entre pantallas, scrollear una lista — todo corre a 60-120fps sin pensar mucho. React Native ha mejorado mucho con la nueva arquitectura (Fabric, Hermes), pero todavía hay un puente entre JavaScript y native, y en operaciones intensivas se nota.
En mi prototipo de prueba (la misma pantalla de dashboard implementada en ambos), Flutter abrió en 280ms en cold start; React Native (Hermes) en 510ms. En un Android de gama media (Moto G50), las diferencias son aún más marcadas. Para una app cuyo selling point es "rápido y sin fricción", esos 230ms importan.
El criterio que más me dolió ignorar: ecosystem
React Native tiene Expo, que es un sueño. Configura, pública, OTA updates, distribución, prebuilt UI components. Para alguien que viene de web React, sentirse como casa toma un día.
Flutter tiene flutter pub, que es funcional pero menos pulido. La distribución a stores es manual (no hay equivalente directo a EAS Build), hay que aprender Gradle y Xcode al menos un poco, y los OTA updates son una zona gris (Shorebird existe, pero no es nativo del framework).
Pesé esto durante una semana. Lo que terminó decidiéndome: prefiero pagar el precio de aprendizaje una vez (Flutter tiene curva al inicio, pero después es estable) que pagar el precio de rendimiento todos los días.
El criterio escondido: hiring local
En Bogotá, encontrar un dev de Flutter es relativamente fácil. La comunidad Flutter latam es activa y hay bootcamps que la enseñan. React Native también, pero los devs de RN tienden a venir de web y muchos prefieren quedarse en web. Los devs de Flutter vienen de mobile y son específicamente mobile.
Cuando VantFi crezca y necesite contratar, prefiero buscar gente que ame mobile, no gente que lo tolere — y esa es una diferencia cultural sutil pero real, que no se ve en un benchmark de performance pero sí en cómo se construye un producto a lo largo de un par de años.
El criterio que sí pesó pero menos: tipo de UI
Material Design 3 (que usa Flutter por default) tiene una opinión fuerte sobre cómo debe verse una app. Si quieres seguir esa opinión, Flutter te da componentes pulidos, transiciones consistentes, y un look-and-feel coherente sin esfuerzo. Para VantFi —una app utilitaria, no un producto donde el branding manda— eso es ventaja, no limitación.
React Native te da más libertad pero también más decisiones. Cada componente lo eliges tú (NativeBase, Tamagui, Gluestack, custom). Cada estilo lo defines tú. Más libertad es bueno cuando tienes un equipo de diseño. Como solo founder, libertad es trabajo extra.
Lo que NO pesó tanto como pensé que pesaría
Reutilizar TypeScript del backend. En la práctica, casi nada del código del backend se reutiliza en mobile. Los tipos de la API los regenero con OpenAPI desde el backend, no los importo directo. Compartir lenguaje en cliente y servidor es bonito en presentaciones de stack, pero en código real produce poco.
Hot reload. Ambos frameworks tienen hot reload bueno. Flutter es ligeramente más rápido en práctica (sub-segundo) pero RN está cerca. No fue un factor real.
Lo que cambiaría si volviera a decidir hoy
Probablemente lo mismo. Pero hay una alternativa nueva que evaluaría con atención: Capacitor + Vue/Svelte + native plugins. Para apps utilitarias como VantFi, una webview con plugins nativos puede ser suficiente, y conserva todo el ecosistema web. La razón por la que no la elegí es la misma del rendimiento percibido: las webviews se sienten distintas a una app nativa, y para una audiencia que abre la app diez veces al día, eso suma.
Mi recomendación general: si tu app es 80% formularios y listas, RN o Capacitor están bien. Si tu app necesita sentirse rápida, animada y nativa, Flutter da mejor resultado por el mismo esfuerzo.