SwiftUI después de 7 años

Artículo original ↗ Discusión en Hacker News ↗

Siete años después de su debut, el framework SwiftUI de Apple es visto por muchos desarrolladores como potente para interfaces simples y declarativas, pero poco fiable y insuficiente para apps complejas y sensibles al rendimiento, especialmente frente a UIKit/AppKit y los patrones clásicos de Cocoa. Los comentaristas destacan la opacidad del manejo de estado, la fragilidad del layout, las APIs faltantes o inestables y el acoplamiento estrecho a las funciones cambiantes del lenguaje Swift como problemas centrales, mientras que una minoría informa buenas experiencias en los sistemas operativos más recientes y sostiene que es “suficientemente bueno” si se aceptan sus compromisos. El debate se amplía hacia la dirección del software de Apple, el coste de los cambios incompatibles de año en año y si alternativas como Flutter, Kotlin Multiplatform o incluso stacks clásicos basados en Objective‑C ofrecen ahora una vía más sostenible.

La propuesta de valor de SwiftUI y la realidad

  • Muchos lo ven como excelente para UIs simples y de “superficie”: listas, formularios, CRUD básico, herramientas administrativas simples y efectos visuales (blur, masks, vistas respaldadas por Metal).
  • Para apps complejas (listas pesadas, layouts personalizados, navegación compleja, windowing sofisticado en macOS, animaciones precisas), la gente reporta problemas de rendimiento, fragilidad de layout y muchos “escape hatches” hacia abajo hasta UIKit/AppKit.
  • Varios lo llaman una “trampa para novatos”: demos fáciles, trabajo real difícil. Los bugs y comportamientos extraños suelen aparecer tarde en proyectos grandes.

Estado, UI declarativa y arquitectura

  • Gran debate entre declarativa-reactiva vs imperativa:
    • Quienes la apoyan: el estado como fuente de verdad y las vistas declarativas reducen bugs de lógica de actualización y facilitan los casos comunes.
    • Quienes la critican: la reactividad de SwiftUI es opaca; es difícil razonar sobre el momento de actualización de las vistas; @State/@Binding/@Observable y herramientas como GeometryReader se ven como “magia” propensa a errores.
  • Un largo subhilo revisita el clásico MVC: algunos sostienen que el MVC “correcto” ya resuelve la mayoría de los problemas de sincronización de estado sin maquinaria reactiva pesada; otros dicen que el propio MVC tiene problemas prácticos (tormentas de eventos, actualización por lotes, rendimiento de layout).

APIs, estabilidad y herramientas

  • Quejas frecuentes sobre:
    • Cambios bruscos de API (por ejemplo, APIs de navegación en evolución, sistemas de estado), condicionales por versión del sistema operativo y diferencias de comportamiento entre versiones de iOS.
    • Documentación deficiente o dispersa; dependencia de videos de WWDC y blogs de terceros.
    • Soporte débil para depuración y profiling (inspección de la jerarquía de vistas, entender re-renders), aunque algunos mencionan un soporte más reciente en Instruments.
  • Algunos argumentan que SwiftUI es “muy bueno” a partir de iOS 26–27 si puedes dejar de soportar versiones antiguas; otros dicen que incluso las versiones actuales siguen teniendo tirones y un alto consumo de CPU en apps reales.

Swift, UIKit/AppKit y la cultura de Apple

  • Fuerte nostalgia por Objective‑C + Cocoa/AppKit/UIKit: se perciben como elegantes, potentes y más adecuados para apps nativas complejas; Swift es visto por algunos como demasiado complicado y con atractivo limitado fuera de las plataformas de Apple.
  • Otros dicen que Swift es una mejora importante y ahora su lenguaje principal en todas partes; ven AppKit/UIKit como verbosos y anticuados.
  • Varios culpan al liderazgo y a decisiones impulsadas por KPIs de haber lanzado Swift/SwiftUI “a medio hacer” durante una década, en contraste con la era anterior de NeXT/Cocoa.

Alternativas y discusión multiplataforma

  • Flutter, Kotlin Multiplatform + Compose, Qt, React Native, WPF, MAUI, HTML/CSS/JS se discuten como alternativas, cada una con distintos compromisos.
  • Algunos ahora prefieren UIKit + asistentes de IA frente a SwiftUI, argumentando que la IA erosiona la ventaja de SwiftUI de “layout fácil”.
  • Consenso: no existe una única “forma correcta”; la elección de herramientas depende de la complejidad de la app, las plataformas objetivo y la tolerancia a las peculiaridades de SwiftUI.