Nadie te lo va a decir en la presentación de ventas. Tampoco en el podcast de tecnología donde el invitado acaba de lanzar su startup. Y desde luego no te lo va a decir el freelance que te presupuesta la app por 8.000 euros usando React Native porque «es prácticamente igual que nativo».
Así que lo digo yo: el desarrollo multiplataforma es un compromiso. No una solución, no el futuro, no la manera inteligente de llegar antes al mercado. Un compromiso. Y como todo compromiso, tiene un precio que alguien acaba pagando.
Qué significa «multiplataforma» en la práctica
Flutter, React Native, .NET MAUI: distintas implementaciones del mismo principio. Escribe el código una vez, despliégalo en iOS y Android. En teoría, eficiencia máxima. En la práctica, una capa de abstracción entre tu código y el sistema operativo que se manifiesta de maneras que no anticipas hasta que ya es tarde.
El rendimiento es el primero. No siempre es crítico, no siempre es perceptible para el usuario casual. Pero está ahí. Las animaciones tienen ese milisegundo de más que el usuario de iOS nota aunque no sepa nombrarlo. El arranque tarda un poco más. El consumo de memoria es mayor. En un iPhone 16 Pro con suficiente RAM, quizás no importa. En el dispositivo de hace tres años de tu abuela, importa mucho.
El segundo es el acceso a las APIs del sistema. Cada vez que Apple lanza una API nueva en la WWDC, los frameworks multiplataforma tardan meses en tener soporte. A veces un año. A veces nunca. ¿Quieres integrar Foundation Model Framework, las nuevas animaciones de Liquid Glass, las funcionalidades de watchOS del año que viene? Espera. O escribe el código nativo de todas formas, que es exactamente lo que querías evitar.
El tercero es más sutil: la experiencia de usuario. Las apps nativas se sienten como apps nativas porque respetan los patrones de interacción del sistema operativo. El gesto de deslizar para volver, las transiciones entre pantallas, el comportamiento del teclado, la integración con el sistema de notificaciones. Cosas pequeñas que, sumadas, crean la diferencia entre una app que parece de Apple y una que parece un portal web disfrazado.
Cuándo el desarrollo multiplataforma sí tiene sentido
Sería deshonesto decir que nunca tiene sentido. Tiene sentido cuando la app es fundamentalmente un formulario con datos. Cuando la lógica de negocio es simple y el diseño no es diferencial. Cuando el presupuesto y el tiempo son genuinamente limitados y las funcionalidades avanzadas del sistema no son necesarias.
Una app interna para la gestión de almacén de una empresa mediana no necesita ser nativa. Una app de reservas con un calendario y un perfil de usuario probablemente tampoco. No todo tiene que ser una obra de arte del ecosistema Apple.
Pero si tu app es tu producto, si la experiencia de usuario es tu diferencia competitiva, si quieres integrar lo que Apple lanza cada año antes que la competencia, si quieres publicar en el App Store y que Apple no la rechace por problemas de rendimiento en los primeros meses, entonces el debate entre nativo y multiplataforma ya no es un debate. Es una decisión tomada.
Por qué en AC Academy enseñamos Swift
No enseñamos Swift porque seamos fundamentalistas de la plataforma. Lo enseñamos porque nuestro objetivo no es que nuestros alumnos sepan usar un framework. Nuestro objetivo es que entiendan el sistema operativo lo suficientemente bien como para construir cualquier cosa sobre él.
Un desarrollador que entiende Swift y SwiftUI puede aprender React Native en semanas si el proyecto lo requiere. La inversa no siempre es cierta. Alguien que ha aprendido desarrollo móvil a través de un framework de abstracción tiene un techo que los desarrolladores nativos no tienen.
Y hay algo más que rara vez se menciona: el mercado laboral para desarrolladores iOS nativos en España, y especialmente en empresas internacionales con equipos remotos, sigue siendo un mercado donde la demanda supera a la oferta. No hay suficientes buenos desarrolladores Swift. Eso tiene consecuencias directas en los salarios y en la empleabilidad a largo plazo.
El desarrollo multiplataforma no es el enemigo. Es una herramienta con un caso de uso específico. El problema no es usarla. El problema es usarla cuando no es la herramienta correcta, y no darte cuenta hasta que ya llevás dos años de deuda técnica encima.
