@ViewBuilder vs struct View en SwiftUI

En el ecosistema actual de la programación Swift, la llegada de SwiftUI supuso una revolución. Pasamos de la construcción imperativa de UIKit a un paradigma declarativo que nos permite describir interfaces complejas con una velocidad asombrosa. Sin embargo, a medida que los proyectos en Xcode crecen, todo iOS developer se enfrenta tarde o temprano a un enemigo común: el “Massive View”.

Empiezas con un simple VStack. Añades una imagen, luego un texto, después un botón, luego lógica condicional para el estado de carga… y de repente, tu propiedad body tiene 300 líneas de código anidado, difícil de leer, imposible de testear y doloroso de mantener.

Para solucionar esto, SwiftUI nos ofrece dos caminos principales para descomponer y organizar nuestra UI:

1. Extraer sub-vistas en nuevas estructuras (struct View).
2. Utilizar propiedades o funciones marcadas con @ViewBuilder.

Pero, ¿cuál es mejor? ¿Son intercambiables? ¿Cuándo debes usar una estructura completa y cuándo una simple variable computada? En este tutorial, desglosaremos la batalla de @ViewBuilder vs struct View en SwiftUI, analizando sus diferencias, semejanzas e impacto en el rendimiento para tus aplicaciones en iOS, macOS y watchOS.

1. El Contendiente Peso Pesado: struct View

En SwiftUI, una vista es, por definición, una estructura (struct) que conforma el protocolo View. Cuando creas un nuevo archivo en Xcode, esto es lo que obtienes por defecto. Es la forma “canónica” y más robusta de encapsular interfaz y comportamiento.

¿Qué es realmente?

Al crear una struct separada, estás definiendo un nuevo tipo en el sistema de Swift. Esto tiene implicaciones profundas. Al ser un tipo de valor (Value Type), es inmutable y ligero, pero al ser una entidad diferenciada, el sistema de SwiftUI puede rastrearla de forma independiente dentro del grafo de dependencias de la vista.

// Ejemplo de struct View
struct UserProfileHeader: View {
    let username: String
    
    var body: some View {
        HStack {
            Image(systemName: "person.circle")
            Text(username)
                .font(.headline)
        }
        .padding()
    }
}

2. El Contendiente Ágil: @ViewBuilder

@ViewBuilder es técnicamente un Result Builder (constructor de resultados), una característica poderosa introducida en Swift. Es el atributo que permite que contenedores como VStack, HStack o Group acepten bloques de código declarativo sin necesidad de devolver explícitamente un array de vistas o usar la palabra clave return.

Muchos desarrolladores utilizan let, var o func decorados con @ViewBuilder para dividir un body gigante en trozos más pequeños dentro del mismo archivo.

¿Qué es realmente?

No es una vista por sí misma, sino un mecanismo para construir vistas. Cuando extraes código a una variable o función auxiliar dentro de tu vista principal, no estás creando un nuevo tipo. Simplemente estás organizando el código. Para el compilador, es como si hubieras copiado y pegado ese código directamente en el body.

// Ejemplo de propiedad con @ViewBuilder dentro de una vista padre
@ViewBuilder
var headerView: some View {
    if isActive {
        Text("Usuario Activo")
    } else {
        Text("Inactivo")
            .foregroundColor(.gray)
    }
}

3. Diferencias Clave: Rendimiento, Estado y Reutilización

Aquí es donde el iOS developer experto se distingue del principiante. La elección entre @ViewBuilder vs struct View en SwiftUI no es solo una cuestión de estilo; afecta directamente a la arquitectura y fluidez de tu app.

A. El Ciclo de Redibujado (The Redraw Cycle)

Esta es la diferencia más crítica para la optimización en SwiftUI.

• El caso de la Struct View:
  SwiftUI es inteligente. Cuando usas una struct View separada, el sistema entiende que es un componente aislado. Si la vista padre (ParentView) se actualiza (redibuja) porque cambió un estado que no afecta a los parámetros pasados a la vista hija (ChildView), SwiftUI puede optar por no redibujar ni recalcular el cuerpo de la hija. Actúa como una barrera de rendimiento natural.
• El caso del @ViewBuilder:
  Una propiedad o función es parte intrínseca de la struct contenedora. Si la vista padre se redibuja por cualquier motivo (aunque sea un cambio en una variable que tu función auxiliar no usa), el cuerpo de tu función @ViewBuilder se reevaluará. No hay aislamiento. Si tienes cálculos complejos o sombras costosas en esa función, se ejecutarán una y otra vez innecesariamente.

B. Gestión de Estado (@State)

• Struct View: Puede tener su propio almacenamiento de estado. Puedes declarar propiedades @State, @StateObject o @FocusState dentro de ella. Esto es vital para componentes reutilizables como un campo de texto personalizado o un botón con animación interna.
• @ViewBuilder: No puede poseer estado propio. Comparte y depende totalmente del estado de la vista contenedora.

C. Inyección de Dependencias

• Struct View: Exige una inyección explícita. Debes pasarle los datos que necesita a través de su inicializador (let user: User). Esto hace que el flujo de datos sea claro y predecible (“One way data flow”).
• @ViewBuilder: Tiene acceso implícito a todas las propiedades (let, var, @Environment) de la vista padre. Esto es cómodo (menos código “boilerplate”), pero acopla fuertemente el fragmento de código a la vista padre.

4. Tutorial Práctico: Refactorizando en Xcode

Vamos a visualizar esto con un ejemplo de programación Swift real. Imaginemos una vista de “Detalle de Producto”.

Paso 1: El caos (The Monolith)

struct ProductDetailView: View {
    let product: Product
    @State private var isZoomed = false
    
    var body: some View {
        ScrollView {
            VStack {
                // Sección de Imagen (Compleja)
                ZStack {
                    Image(product.imageName)
                        .resizable()
                        .aspectRatio(contentMode: isZoomed ? .fill : .fit)
                        .onTapGesture { isZoomed.toggle() }
                    
                    if !isZoomed {
                        Image(systemName: "magnifyingglass")
                    }
                }
                
                // Sección de Información
                Text(product.title).font(.largeTitle)
                Text(product.description).foregroundColor(.secondary)
                
                // Botón de Compra
                Button("Comprar") { ... }
                    .padding()
                    .background(Color.blue)
            }
        }
    }
}

Paso 2: Limpieza con @ViewBuilder

Si solo queremos organizar el código para leerlo mejor, usamos @ViewBuilder.

extension ProductDetailView {
    @ViewBuilder
    var imageSection: some View {
        ZStack {
            Image(product.imageName) // Acceso directo a 'product' del padre
                .resizable()
                .aspectRatio(contentMode: isZoomed ? .fill : .fit) // Acceso directo a state
                .onTapGesture { isZoomed.toggle() }
            
            if !isZoomed {
                Image(systemName: "magnifyingglass")
            }
        }
    }
}

Veredicto: Es rápido y limpio, pero si cambia algo en ProductDetailView que no tenga nada que ver con la imagen, imageSection se recalculará.

Paso 3: Optimización con struct View

Si la imagen es compleja o queremos reutilizar este visor de imágenes en otra parte de la app, creamos una struct.

struct ProductImageView: View {
    let imageName: String // Dependencia explícita
    @State private var isZoomed = false // Estado aislado/interno
    
    var body: some View {
        ZStack {
            Image(imageName)
                .resizable()
                .aspectRatio(contentMode: isZoomed ? .fill : .fit)
                .onTapGesture { isZoomed.toggle() }
            
            if !isZoomed {
                Image(systemName: "magnifyingglass")
            }
        }
    }
}

Veredicto: Ahora ProductImageView es un componente independiente. Xcode puede previsualizarlo (Preview) por separado, y es mucho más eficiente en términos de rendimiento.

5. La Matriz de Decisión: ¿Cuándo usar qué?

Para optimizar tu desarrollo en SwiftUI y Swift, imprime esta lista y tenla cerca de tu monitor:

Usa variables o funciones @ViewBuilder cuando:

1. Organización visual: Solo quieres dividir un body largo en secciones lógicas (Header, Content, Footer) para mejorar la legibilidad.
2. Lógica simple: Necesitas renderizar condicionalmente (if/else) pequeñas partes de UI.
3. Acoplamiento alto: El fragmento de vista necesita acceder a muchas variables @Environment o @State del padre y pasarlas todas como parámetros a una struct sería excesivamente tedioso.
4. No hay estado propio: El fragmento no necesita gestionar su propia interacción o animación interna.

Usa struct View cuando:

1. Reutilización: El componente se usará en más de un lugar de la app (ej: una celda de lista personalizada, un botón de estilo propio).
2. Estado independiente: El componente necesita su propio @State (ej: un formulario de entrada, un contador).
3. Optimización de rendimiento: Quieres aislar el redibujado. Si el padre cambia frecuentemente, la hija no debería verse afectada.
4. Complejidad: El componente es lo suficientemente complejo como para merecer su propio archivo y sus propios tests.
5. Previews de Xcode: Quieres poder trabajar en el diseño de ese componente de forma aislada en el Canvas.

6. Semejanzas Importantes

A pesar de sus diferencias en la arquitectura interna, vale la pena recordar qué tienen en común para no tener miedo de usar ambos:

• Composición: Ambos son ciudadanos de primera clase en la composición de SwiftUI. Puedes poner una struct View dentro de un @ViewBuilder y viceversa.
• Tipado: Ambos devuelven some View. Swift oculta la complejidad del tipo concreto (que suele ser monstruoso como TupleView<(Text, Image)>), permitiéndote trabajar con abstracciones limpias.
• Sintaxis: Gracias a las mejoras en Swift, la sintaxis visual es casi idéntica dentro del body.

Conclusión

En la programación Swift moderna, no existe un ganador absoluto en la batalla @ViewBuilder vs struct View en SwiftUI. Ambas son herramientas esenciales.

El error del novato es usar @ViewBuilder para todo por pereza de crear nuevos archivos. El error del purista es crear una struct para cada etiqueta de texto, llenando el proyecto de cientos de micro-archivos innecesarios.

Como iOS developer, tu objetivo debe ser el equilibrio:

1. Empieza prototipando rápido en el body.
2. Usa @ViewBuilder para organizar ese body en secciones legibles (header, content, footer).
3. Refactoriza a struct View en cuanto detectes: Reutilización, Complejidad de Estado o Problemas de Rendimiento.

Dominar esta distinción es lo que te permitirá construir aplicaciones en Xcode que no solo se vean bien en iOS, macOS y watchOS, sino que funcionen con una fluidez perfecta a 60 (o 120) cuadros por segundo.

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