VStack vs LazyVStack en SwiftUI

En el mundo de la programación Swift y el desarrollo de interfaces declarativas, la gestión del diseño y el rendimiento es una batalla constante. Cuando Apple introdujo SwiftUI, nos dio VStack, una herramienta poderosa pero a veces malinterpretada. Un año después, en iOS 14, llegó LazyVStack, prometiendo resolver los problemas de memoria en listas largas.

Para un iOS Developer, elegir entre estos dos contenedores no es solo una cuestión de preferencia, sino de arquitectura. Una elección incorrecta puede llevar a una aplicación lenta, con caídas de frames (FPS) y un consumo excesivo de memoria. En este tutorial técnico, desglosaremos las diferencias críticas, el comportamiento en memoria y los casos de uso específicos para VStack vs LazyVStack en SwiftUI y Xcode, abarcando iOS, macOS y watchOS.

El Contendiente Clásico: VStack

El VStack (Vertical Stack) es el bloque de construcción fundamental. Su comportamiento es “codicioso” (greedy) o de carga ansiosa (eager loading). Esto significa que SwiftUI renderizará e inicializará todas las vistas contenidas dentro del stack inmediatamente, independientemente de si están visibles en la pantalla o no.

Imagina que tienes una lista de 1000 elementos complejos. Si usas un VStack dentro de un ScrollView, el sistema intentará crear las 1000 filas en el momento en que la vista aparece. Esto provoca un pico de memoria instantáneo y un retraso perceptible en la navegación inicial.

¿Cuándo usar VStack?

• Cuando tienes un número pequeño y fijo de elementos (por ejemplo, un formulario de login, una tarjeta de perfil).
• Cuando necesitas que todas las vistas estén vivas para mantener su estado interno o animaciones sincronizadas.
• Cuando el contenido no requiere desplazamiento (scroll) o es muy corto.

El Retador Moderno: LazyVStack

Introducido en Xcode 12, LazyVStack cambia las reglas del juego. Como su nombre indica, es “perezoso” (lazy). Solo renderiza las vistas que están actualmente visibles en el viewport (la pantalla del dispositivo), más un pequeño margen de seguridad (buffer) para asegurar un desplazamiento suave.

A medida que el usuario hace scroll, LazyVStack crea las nuevas filas y destruye (o recicla, dependiendo de la gestión interna de grafos de SwiftUI) las que salen de la pantalla. Esto es análogo al comportamiento de UITableView o UICollectionView en UIKit, pero con una sintaxis mucho más limpia en Swift.

Experimento Práctico: Midiendo el Ciclo de Vida

La mejor manera de entender la diferencia para un iOS Developer es mediante el código. Vamos a crear una vista simple que imprima en la consola cuándo se inicializa.

import SwiftUI

struct RowView: View {
    let id: Int
    
    init(id: Int) {
        self.id = id
        print("Iniciando RowView \(id)")
    }
    
    var body: some View {
        Text("Fila \(id)")
            .padding()
            .frame(maxWidth: .infinity)
            .background(Color.blue.opacity(0.1))
            .cornerRadius(8)
    }
}

struct StackComparisonView: View {
    var body: some View {
        ScrollView {
            // CAMBIA ESTO: VStack vs LazyVStack
            LazyVStack(spacing: 16) {
                ForEach(0..<1000, id: \.self) { i in
                    RowView(id: i)
                }
            }
            .padding()
        }
    }
}

Resultados del Experimento:

• Con VStack: Al ejecutar la app, verás en la consola de Xcode que se imprimen los logs de “Iniciando RowView…” desde el 0 hasta el 999 instantáneamente. La app tardará un momento en responder.
• Con LazyVStack: Solo verás los logs de las filas visibles (por ejemplo, del 0 al 15). A medida que haces scroll, verás aparecer los nuevos logs. El inicio de la app es inmediato.

Diferencias Críticas de Diseño (Layout)

Más allá del rendimiento, hay diferencias de comportamiento en el diseño que todo experto en programación Swift debe conocer. VStack y LazyVStack no calculan el espacio de la misma manera.

1. Cálculo de Ancho y Spacers

Un VStack calcula el tamaño de todos sus hijos antes de renderizarse. Sabe exactamente qué tan ancho es el elemento más ancho y ajusta el contenedor. Un LazyVStack, al no conocer el tamaño de los elementos que aún no se han cargado, prefiere ocupar todo el ancho disponible del contenedor padre (generalmente el ScrollView) por defecto.

Además, el uso de Spacer() es diferente. En un VStack, un Spacer empujará el contenido para llenar el espacio. En un LazyVStack, un Spacer no se expandirá a menos que se le dé una altura explícita o el contenedor tenga una altura fija, ya que el stack perezoso intenta contraerse verticalmente a su contenido.

2. Pinned Views (Secciones Pegajosas)

Una característica exclusiva de los stacks perezosos (tanto LazyVStack como LazyHStack) es la capacidad de “fijar” vistas, similar a los “sticky headers” de UIKit. El VStack estándar no soporta esto nativamente.

struct StickyHeaderExample: View {
    var body: some View {
        ScrollView {
            LazyVStack(spacing: 10, pinnedViews: [.sectionHeaders]) {
                Section(header: HeaderView(title: "Sección A")) {
                    ForEach(0..<10) { _ in ItemView() }
                }
                
                Section(header: HeaderView(title: "Sección B")) {
                    ForEach(0..<10) { _ in ItemView() }
                }
            }
        }
    }
}

struct HeaderView: View {
    let title: String
    var body: some View {
        Text(title)
            .font(.headline)
            .frame(maxWidth: .infinity)
            .padding()
            .background(Color(.systemBackground)) // Importante para ocultar el contenido al hacer scroll
            .overlay(Divider(), alignment: .bottom)
    }
}

struct ItemView: View {
    var body: some View {
        RoundedRectangle(cornerRadius: 10)
            .fill(Color.orange.opacity(0.2))
            .frame(height: 50)
            .padding(.horizontal)
    }
}

El Evento .onAppear() y Ciclo de Vida

Este es un punto de dolor común en la programación Swift. Si necesitas cargar datos de la red cuando una fila aparece (paginación infinita), debes usar LazyVStack.

• En VStack: El modificador .onAppear de cada hijo se dispara casi simultáneamente al inicio, ya que todas las vistas se crean a la vez. No sirve para paginación.
• En LazyVStack: El modificador .onAppear se dispara solo cuando la fila entra en el área visible. Esto es ideal para detectar cuándo el usuario llega al final de la lista y pedir más datos a la API.

Consideraciones para macOS y watchOS

Como desarrolladores que usamos Xcode para todo el ecosistema, debemos pensar en las otras plataformas:

• watchOS: El Apple Watch tiene recursos limitados. Usar VStack para listas largas puede bloquear la interfaz fácilmente (“hang”). LazyVStack es casi obligatorio para colecciones de más de 20 elementos en el reloj.
• macOS: Aquí el tamaño de la ventana cambia. LazyVStack se adapta mejor al redimensionamiento dinámico de ventanas que un VStack cargado, que podría requerir recalcular el layout de miles de elementos invisibles al cambiar el ancho de la ventana.

¿Cuándo NO usar LazyVStack?

Podría parecer que “Lazy” es siempre mejor, pero tiene sus desventajas. Al hacer scroll rápido, el procesador debe calcular, crear y renderizar vistas en milisegundos. Si tus vistas son extremadamente complejas (muchos gradientes, sombras, trazados complejos), podrías notar pequeños tirones (stuttering) al hacer scroll rápido porque el UI thread está saturado creando vistas.

En esos casos específicos, si la lista no es infinita (digamos, 50 elementos complejos), un VStack podría ofrecer un scroll más suave (mantequilla) porque todo el trabajo pesado se hizo al principio, aunque el tiempo de carga inicial sea mayor.

Conclusión

La elección entre VStack vs LazyVStack en SwiftUI es una decisión de ingeniería. No uses LazyVStack por defecto para todo; úsalo cuando tengas listas dinámicas, largas o necesites “sticky headers”. Usa VStack para estructuras de layout estáticas y contenedores pequeños.

Dominar estas diferencias te convertirá en un mejor iOS Developer, capaz de crear aplicaciones en Swift que no solo se ven bien, sino que se sienten fluidas y respetan la batería y memoria del usuario.

Si tienes cualquier duda sobre este artículo, contacta conmigo y estaré encantado de ayudarte 🙂. Puedes contactar conmigo en mi perfil de X o en mi perfil de Instagram