Por qué construimos aplicaciones nativas de iOS con Swift en lugar de marcos multiplataforma
La tentación multiplataforma
Seamos claros: nos encanta Flutter. Lo usamos para muchos proyectos de clientes donde el alcance multiplataforma es más importante que las características específicas de la plataforma. React Native también es sólido. Pero para nuestras propias aplicaciones iOS impulsadas por IA —las que aprovechan CoreML, usan la cámara a 60fps y necesitan ser indistinguibles de las aplicaciones de Apple— elegimos consistentemente Swift nativo y SwiftUI.
Esta no es una postura ideológica. Es una decisión práctica basada en enviar productos reales y medir lo que importa: rendimiento, retención de usuarios, calificaciones en el App Store y velocidad de desarrollo.
La brecha de rendimiento de CoreML es real
Cuando tu aplicación ejecuta un pipeline de ML realizando visión por computadora a 60fps, la sobrecarga del puente de los marcos multiplataforma se convierte en un cuello de botella real. La integración de CoreML en Swift es sin sobrecarga — el modelo se ejecuta en el Neural Engine, los resultados regresan como tipos Swift nativos, y la interfaz se actualiza en el mismo fotograma.
Comparamos un modelo de detección de objetos YOLOv8 en tres enfoques: Swift nativo con CoreML, Flutter con un puente de canal de plataforma a CoreML, y React Native con un módulo nativo. Los resultados fueron contundentes:
Swift nativo: 12ms de tiempo de inferencia promedio. Puente Flutter: 28ms (el puente añade ~16ms de sobrecarga de serialización por fotograma). React Native: 35ms. Con entrada de cámara a 30fps, esa sobrecarga del puente consume casi la mitad de tu presupuesto de fotogramas. A 60fps, es game over para multiplataforma.
Para aplicaciones donde la inferencia de IA ocurre ocasionalmente (un filtro de foto, una característica de análisis de texto), esta sobrecarga es insignificante. Pero para IA en tiempo real —procesamiento de cámara en vivo, análisis continuo de sensores, transcripción de audio en streaming— Swift nativo con CoreML es la única opción que ofrece una experiencia fluida.
SwiftUI se ha convertido en una herramienta de productividad muy potente
SwiftUI ha madurado significativamente con iOS 17 y 18. Los navigation stacks, las macros observable y las nuevas APIs de animación rivalizan con cualquier cosa en el mundo multiplataforma. Nuestra velocidad de iteración con SwiftUI previews es en realidad más rápida que hot reload en muchos casos, porque los previews se renderizan sin recompilar toda la aplicación.
La macro Observable en Swift 5.9 eliminó la mayoría del código repetitivo que hacía que la gestión del estado en SwiftUI fuera dolorosa. Combinado con el nuevo sistema de Navigation, construir flujos complejos de múltiples pantallas es ahora sencillo y type-safe. Pasamos menos tiempo lidiando con el framework y más tiempo construyendo características.
Para aplicaciones que necesitan sentirse nativas — gestos apropiados de iOS, haptics, integración de Dynamic Island, Live Activities, widgets — SwiftUI te los proporciona gratis. Los frameworks multiplataforma no pueden acceder a estas características o requieren implementaciones complejas de canales de plataforma que anulan el ahorro de tiempo.
La ventaja de la App Store
Apple revisa las aplicaciones y puede notar la diferencia. Las aplicaciones Swift nativas obtienen procesos de revisión más suave, acceso a las últimas APIs el primer día y mejores oportunidades de aparición. Apple promueve activamente aplicaciones que muestren sus últimas características de plataforma — y no puedes usar esas características desde frameworks multiplataforma hasta que alguien construya un puente, lo que a menudo toma meses.
Nuestras aplicaciones nativas tienen una calificación promedio en la App Store de 4.7 estrellas. Las reseñas positivas más comunes mencionan la velocidad y cómo la aplicación se siente como si perteneciera a iOS. Ese sentimiento nativo es casi imposible de replicar con frameworks multiplataforma, especialmente para animaciones, transiciones e interacciones de gestos.
Cuándo es la opción correcta multiplataforma
Las plataformas cruzadas tienen sentido cuando: tu aplicación es principalmente una interfaz CRUD respaldada por una API, necesitas iOS y Android desde el primer día con un presupuesto limitado, todas tus funciones de IA están del lado del servidor, o estás construyendo un MVP para validar un concepto antes de invertir en nativo. Usamos Flutter exactamente para estos escenarios en nuestro trabajo con clientes.
Para todo lo demás — especialmente aplicaciones con ML en el dispositivo, canalizaciones de cámara personalizadas, integración de ARKit, o integración profunda del SO como HealthKit o HomeKit — ve nativo. La inversión inicial se amortiza a sí misma en rendimiento, satisfacción del usuario y mantenibilidad a largo plazo.
Nuestra recomendación
Si eres una startup decidiendo entre nativo y multiplataforma, hazte una pregunta: ¿está la propuesta de valor central de tu aplicación vinculada a una capacidad específica de la plataforma? Si la respuesta es sí — y para la mayoría de aplicaciones de IA lo es — ve nativo. Si la respuesta es no, Flutter o React Native te servirán bien y te ahorrarán tiempo.
En iHux, somos agnósticos en cuanto a la plataforma en nuestras recomendaciones y específicos de la plataforma en nuestra ejecución. Te diremos honestamente cuál es el enfoque correcto para tu producto, y luego lo construiremos adecuadamente.