He publicado apps en producción con Swift, Kotlin y Flutter, y he heredado muchas hechas con React Native. Esta no es una comparativa de pruebas de rendimiento: es la respuesta que doy a fundadores que necesitan decidir esta semana y mantener esa decisión durante los próximos dos años.
La versión corta
- Flutter: si necesitas ambas plataformas, comportamiento compartido y un equipo capaz de mantener tanto las integraciones específicas como la interfaz común.
- Desarrollo nativo: si las funciones propias de iOS o Android, la integración con el sistema o el comportamiento específico de cada plataforma son centrales y puedes mantener ambas apps.
- React Native: si ya tienes un equipo React capaz de mantener las dependencias de JavaScript y los módulos nativos. Incluye las actualizaciones y las integraciones en la decisión.
A continuación explico por qué.
Desarrollo nativo: Swift y Kotlin
Dos aplicaciones para dos plataformas implican trabajo de implementación y publicación por separado, pero no todas las tareas del proyecto se duplican. Las decisiones de producto, buena parte del diseño y un backend compartido pueden ser comunes. Pide a los proveedores que indiquen qué tareas se comparten y cuáles se desarrollan y prueban por separado. El desarrollo de apps nativas es útil cuando el requisito incluye acceso directo a funciones de la plataforma.
Qué consigues: acceso directo a los SDK que admiten tus dispositivos y versiones del sistema operativo. Widgets, App Clips, Live Activities, CarPlay, Wear y las integraciones de cámara o aprendizaje automático tienen requisitos propios. Aun así, debes verificar disponibilidad, permisos, comportamiento en dispositivos y restricciones de publicación. El desarrollo nativo no elimina ese trabajo.
Cuándo elegirlo: cuando la calidad de la app es una ventaja competitiva, las funciones propias de cada plataforma son esenciales, necesitas controlar al máximo rendimiento y memoria, o puedes mantener dos equipos especializados.
Flutter
Flutter utiliza su propio sistema de renderizado en lugar de envolver cada control nativo. Esto facilita compartir una interfaz personalizada y coherente, pero las convenciones de cada plataforma y la accesibilidad siguen requiriendo diseño y pruebas en ambos sistemas operativos. El servicio de desarrollo de apps con Flutter detalla la implementación, las pruebas en dispositivos y la entrega.
Qué consigues: lógica de aplicación y buena parte de la interfaz compartidas entre plataformas. Una corrección común puede beneficiar a ambas apps, aunque las integraciones nativas, la accesibilidad y el comportamiento del sistema operativo necesitan pruebas específicas. Es una opción útil para productos con una interfaz compartida de forma deliberada.
Qué implica: existe una capa adicional para acceder a funciones nuevas del sistema operativo y los binarios pueden ser más grandes. Las integraciones muy específicas pueden requerir canales de plataforma: código nativo que también tendrás que mantener.
Cuándo elegirlo: cuando necesitas ambas plataformas, una interfaz personalizada y prefieres concentrar el presupuesto en un equipo sólido.
React Native
Un equipo con experiencia en React puede adaptarse rápidamente a React Native, pero el código web no se convierte automáticamente en una interfaz móvil reutilizable. Revisa los módulos nativos, el mantenimiento de los paquetes, las actualizaciones y quién se hará cargo de ellos después del lanzamiento.
Qué implica: mantener las dependencias. Una app React Native combina tu código con paquetes de la comunidad cuyo mantenimiento no controlas. En las aplicaciones que heredo, las actualizaciones suelen generar trabajo imprevisto.
Cuándo elegirlo: cuando ya tienes un equipo React y un producto web con lógica que puede compartirse. Si tienes que formar el equipo desde cero, también conviene valorar Flutter.
Cómo comparar los costes
Una estimación útil compara los mismos flujos y criterios de aceptación en cada tecnología. Pide a cada proveedor que separe el trabajo compartido de producto y backend de las apps, integraciones, pruebas, preparación de publicaciones y mantenimiento. La comparación debe mostrar el trabajo concreto; un multiplicador por tecnología lo oculta.
- Usa las mismas especificaciones. Define los mismos flujos, dispositivos, versiones del sistema operativo e integraciones para todos los presupuestos. Separa las funciones opcionales.
- Separa el trabajo compartido. Distingue diseño, backend y producto de la implementación para iOS y Android, las integraciones y las pruebas en dispositivos.
- Presupuesta la responsabilidad de publicación. Incluye firma, envío a las tiendas, seguimiento de errores, compatibilidad con nuevas versiones y quién actuará cuando falle un módulo o complemento.
- Compara dos plataformas con un lanzamiento por etapas. Si el presupuesto obliga a empezar por una, indica qué usuarios y funciones esperarán y qué resultados justificarán invertir en la segunda.
El mantenimiento aclara la diferencia de costes. Cuenta cuántas personas pueden publicar cada app, qué comprobaciones repites y con qué frecuencia las dependencias o los cambios del sistema operativo exigen trabajo específico. Incluye estos supuestos junto al presupuesto inicial en lugar de calcular el mantenimiento como un porcentaje genérico.
La disponibilidad del equipo también cuenta
La disponibilidad de desarrolladores depende de su experiencia, ubicación, remuneración y de los requisitos técnicos del producto. Antes de elegir una tecnología, comprueba qué candidatos puedes encontrar realmente y qué experiencia requieren sus integraciones nativas. Una tecnología adecuada para el producto, pero para la que no encuentras personal, supone un riesgo para la entrega.
La disponibilidad del equipo influye en la decisión y rara vez aparece en las comparativas técnicas. Una arquitectura excelente para la que no encuentras desarrolladores puede ser peor que una buena arquitectura que sí puedes mantener.
Si ya tienes una app y estás pensando en cambiar
Una reescritura consume tiempo que podría dedicarse a desarrollar el producto. Antes de comprometerte, compárala con reparar la app o migrarla de forma incremental. Es más fácil justificarla cuando:
- No encuentras desarrolladores para la tecnología actual con un presupuesto razonable.
- Un requisito de la plataforma obligará a hacer ese trabajo durante los próximos doce meses.
- El código actual no cumple los requisitos básicos: consulta la lista de auditoría técnica. En ese caso, el problema va más allá de la tecnología.
- Mantienes dos apps nativas con un equipo demasiado pequeño incluso para una.
«Nuestros desarrolladores prefieren otra tecnología» no basta para justificar una reescritura, aunque muchas empiecen por ese motivo.
Las preguntas que realmente lo deciden
No basta con preguntar cuál es más rápido. Estas preguntas ayudan más:
- ¿Quién mantendrá esto dentro de dos años? Elige una tecnología para la que puedas contratar en tu ciudad o dentro de tu presupuesto. Una elección técnica perfecta sin desarrolladores disponibles es una mala elección.
- ¿Cuánto se personalizará la interfaz? Una interfaz muy personalizada favorece Flutter. Una interfaz convencional para cada plataforma favorece el desarrollo nativo.
- ¿Necesitas una función de la plataforma desde el primer día? Especifica la API, el SDK, el dispositivo y el comportamiento requerido. Comprueba que la tecnología elegida lo admita actualmente y quién se encargará de mantenerlo. El acceso nativo puede reducir el riesgo de las capas de compatibilidad, pero no hace que todas las integraciones sean sencillas.
- ¿Ya existe una app web? Si está hecha con React y su lógica se puede compartir de verdad, React Native gana muchos puntos.
- ¿Cuál es el presupuesto real? Compara el mismo alcance de lanzamiento con tu presupuesto real. Si no alcanza para las dos plataformas, decide cuál lanzarás primero, de qué dependerá la segunda y cómo mantendrás la primera.
Lo que no importa tanto como crees
- Rendimiento por reputación. Si importan el arranque, la fluidez, la memoria, el trabajo en segundo plano o la comunicación con dispositivos, mide los flujos críticos en los dispositivos objetivo. La reputación de una tecnología no sustituye esas pruebas.
- «No parece nativa». A menudo es un problema de diseño y atención al detalle que puede aparecer con cualquier tecnología.
- Predecir qué tecnología ganará. Revisa la frecuencia de publicaciones, las dependencias y el proceso de actualización que realmente vas a adoptar. Tu equipo necesita una elección mantenible, no una predicción.
Si vas a heredar una app en lugar de empezar desde cero, la tecnología es una cuestión secundaria. Empieza por lo que debería revisar una auditoría técnica.