SwiftUI Series 01 ｜ Los límites aplicables de SwiftUI

Cuando entré en contacto por primera vez con SwiftUI, las preguntas más frecuentes fueron:

• ¿Puede reemplazar a UIKit?
• ¿Todos los proyectos nuevos deberían utilizar SwiftUI?
• ¿Vale la pena reubicar el antiguo proyecto?

Estas cuestiones son, por supuesto, importantes, pero si la discusión se centra en el “reemplazo” desde el principio, el juicio a menudo se llegará al extremo. Una pregunta más práctica sería:

¿Qué tipo de complejidad de página maneja mejor SwiftUI y qué tipo de problemas no necesariamente domina?

Sólo si primero se responde claramente a esta pregunta, las siguientes preguntas “debería usarse” y “en qué medida” tendrían significado práctico.

1. El verdadero poder de SwiftUI es que pone en primer lugar “cómo se asignan los cambios de estado a las interfaces”

La idea predeterminada de UIKit es más parecida a:

• ver primero
• Ve y actualiza la vista nuevamente.
• Luego manejar la relación de sincronización entre múltiples componentes de la interfaz de usuario.

La idea predeterminada de SwiftUI se acerca más a:

• Estado preexistente
• Luego describe “cómo debería verse la interfaz en este estado”

Esto significa que, naturalmente, es más adecuado para páginas donde “la principal complejidad de la interfaz proviene de la expresión del estado”. Por ejemplo:

• Vaciar / cargar / cargar / error cambiar a la página obvia
• página de formulario
• Página de configuración
• Mostrar página de detalles
• Una página donde se vinculan varios widgets impulsados por un conjunto de estados comerciales

Por supuesto, estas páginas se pueden escribir en UIKit, pero muchas relaciones de sincronización a menudo deben mantenerse manualmente. La ventaja de SwiftUI es precisamente que facilita la expresión de dichas relaciones en su conjunto.

2. Es particularmente adecuado para páginas comerciales donde “el estado es más importante que los detalles de la interacción”

La verdadera dificultad con muchas páginas comerciales es:

• ¿Cuál es la situación actual?
• Qué mostrar en diferentes estados
• ¿Qué áreas deben cambiarse conjuntamente después de una determinada acción empresarial?

Por ejemplo:

• Centro personal
• Página de configuración
• Página de detalles del artículo
• Página de resultados de búsqueda
• Página de detalles del pedido

Estas páginas rara vez requieren niveles extremos de coordinación de desplazamiento o diseño de gestos, pero sí implican mucho:

• Cambio de estado
• Visualización condicional
• Combinación de componentes
• Actualización parcial

Estas cosas es donde SwiftUI resulta más útil.

3. También es muy adecuado para páginas con “iteraciones rápidas y cambios frecuentes en la interfaz de usuario”.

Esto es muy importante en equipos reales.

Algunas páginas no tienen cambios frecuentes de producto:

• Revisión de redacción
• Cambios estructurales
• Cambiar el orden de las cartas.
• Cambiar la condición de visualización de un determinado módulo.

En tales escenarios, la ventaja de SwiftUI a menudo no es solo “menos código”, sino también la menor carga mental de modificar la estructura de la interfaz de usuario. Es más fácil tratar la página como un árbol de estructura basado en estados para modificar, en lugar de parchear de un lado a otro entre muchas vistas parciales.

Entonces, si la realidad para un equipo es que “las páginas cambian con frecuencia”, SwiftUI suele resultar muy atractivo.

4. Pero SwiftUI no es naturalmente adecuado para todas las “páginas complejas”

Éste es también el punto que es necesario dejar más claro.

Una situación común es que cuando escuchas “SwiftUI es más moderno”, inconscientemente lo equiparas con “todas las páginas son más adecuadas”. Pero en proyectos reales, la complejidad de las páginas complejas proviene de diferentes fuentes.

Si la dificultad principal de una página es:

• Control de desplazamiento extremadamente fino
• Mucha coordinación de gestos de bajo nivel.
• Tiempo de animación muy personalizable.
• Control extremadamente exigente sobre los detalles de renderizado e interacción.

Entonces es posible que SwiftUI no sea naturalmente más fácil.

es:

• Algunas habilidades deben ser eludidas.
• A veces hay que mezclar UIKit
• Algunos comportamientos subyacentes son más costosos de depurar.

Por tanto, “la página es compleja” no es un criterio en sí mismo, la clave está en dónde es compleja.

5. Un juicio más práctico: ¿La dificultad central de la página es “expresión de estado” o “control subyacente”?

Este es mi método de juicio más común.

Si la dificultad principal de la página es:

• Cómo asignar múltiples estados comerciales a la interfaz
• Cómo combinar componentes de forma natural a medida que cambia el estado.
• Cómo mantener clara la estructura de la página.

Entonces SwiftUI suele ser adecuado.

Si la dificultad principal de la página es:

• Cómo controlar con precisión las interacciones subyacentes.
• Cómo coordinar el comportamiento de desplazamiento complejo
• Cómo implementar comportamientos de diseño y animación no estándar

Ese UIKit tiende a ser más estable, o al menos más “controlable”.

Este juicio no es absoluto, pero es bastante práctico en proyectos reales. Puede guiar la selección diaria mejor que la pregunta “¿Puede SwiftUI reemplazar a UIKit?”

6. La estrategia más realista en proyectos antiguos suele ser “mezclar según límites”

Si el proyecto ya tiene una estructura UIKit madura, el problema más probable es una “imaginación de migración demasiado ideal”.

En proyectos reales, el camino más común y estable suele ser:

• Utilice SwiftUI primero para páginas nuevas
• Las páginas UIKit estables no se pueden cambiar fácilmente
• Mézclalo cuando sea necesario
• No perseguir la migración completa de una sola vez

Porque los costos de la migración en sí mismos son costos comerciales. Si el cambio de marco no aporta beneficios claros y tiene solo el propósito de “unificar la pila”, es probable que la ganancia supere la pérdida.

7. Un malentendido común: tratar a SwiftUI como “una versión mejorada de sintaxis de UIKit”

Cuando aprendí por primera vez esta parte de SwiftUI, todavía tenía estas preguntas en mente:

• ¿Esta vista solo se crea una vez?
• ¿Cuándo quiero actualizar manualmente?
• No es como UIKit donde sólo necesitas cambiarlo directamente.

Estas dudas son normales, pero si te quedas en este punto de vista durante mucho tiempo, será difícil utilizar realmente bien SwiftUI. Porque SwiftUI es una forma completamente diferente de organizar la interfaz.

Requiere priorizar pensar en:

• ¿Quién es responsable del estatus?
• Cómo asignar este estado a la interfaz de usuario
• ¿La actualización de la interfaz es parte del flujo de estado?

Una vez que todavía usas el pensamiento de UIKit, SwiftUI puede fácilmente terminar volviéndose “aparentemente declarativo, pero en realidad la lógica es más confusa”.

8. Conclusión: Si SwiftUI es adecuado o no, no depende de si es nuevo o no, sino de la fuente de complejidad de la página.

Para decirlo en forma más breve, diría:

SwiftUI es más adecuado para páginas cuya complejidad central proviene principalmente de la expresión de estado, la combinación de interfaces y la frecuencia de iteración; y para aquellas páginas cuya complejidad proviene principalmente de la interacción subyacente y el control fino, puede que no sea naturalmente dominante.

Entonces el verdadero juicio práctico es:

• ¿Qué tiene de complicada esta página?
• ¿Puede SwiftUI lograr este tipo de complejidad?

Una vez que se responde claramente a esta pregunta, la selección no suele ser demasiado confusa.