SwiftUI vs UIKit

Si eres un iOS Developer o estás dando tus primeros pasos en la programación Swift, es muy probable que te hayas topado con la gran encrucijada del desarrollo moderno en los ecosistemas de Apple: SwiftUI vs UIKit.

Durante más de una década, UIKit fue el rey indiscutible para la creación de interfaces de usuario en el iPhone y el iPad. Sin embargo, con la llegada de SwiftUI en 2019, Apple introdujo un cambio de paradigma radical que transformó por completo cómo interactuamos con Xcode y cómo estructuramos nuestras aplicaciones no solo en iOS, sino también en macOS y watchOS.

En este tutorial extenso y detallado, desglosaremos las principales diferencias y semejanzas entre ambos frameworks. Analizaremos sus arquitecturas, curvas de aprendizaje, gestión de estado y cómo puedes hacer que convivan en un mismo proyecto utilizando Swift.

1. El Contexto Histórico: De UIKit a SwiftUI

Para entender el debate SwiftUI vs UIKit, primero debemos comprender de dónde venimos y hacia dónde nos dirigimos.

¿Qué es UIKit?

UIKit es el framework clásico de Apple para construir interfaces de usuario en iOS y tvOS. Basado en Objective-C (aunque ahora interactuamos con él predominantemente mediante Swift), utiliza un enfoque imperativo. Esto significa que como desarrollador, debes decirle al sistema cómo hacer las cosas paso a paso.

Si quieres que un botón cambie de color cuando el usuario hace clic, debes escribir código que intercepte el evento del clic, busque la referencia al botón en la memoria y cambie explícitamente su propiedad de color de fondo. Además, UIKit está fuertemente ligado al patrón de diseño MVC (Model-View-Controller), delegando una gran cantidad de lógica a los UIViewController.

¿Qué es SwiftUI?

SwiftUI, por otro lado, es un framework moderno basado completamente en la programación Swift. Su enfoque es declarativo. En lugar de dictar cómo cambia la interfaz, declaras cómo debería verse la interfaz en función de un estado (State) determinado.

Si el estado cambia, SwiftUI se encarga automáticamente de redibujar la pantalla. Esto elimina la necesidad de gestionar manualmente las actualizaciones de la vista, reduciendo drásticamente la cantidad de código repetitivo (“boilerplate”) y los errores humanos (como olvidar actualizar un label cuando cambia un dato).

2. Principales Semejanzas

A pesar de sus diferencias fundamentales, ambos frameworks comparten características importantes que facilitan la transición para cualquier iOS Developer.

• Lenguaje Base: Ambos utilizan Swift. Aunque UIKit tiene sus raíces en Objective-C, Apple ha optimizado las APIs de UIKit a lo largo de los años para que se sientan naturales y “Swift-friendly”.
• Integración con Xcode: Ambos están profundamente integrados en Xcode. Puedes depurar, perfilar y empaquetar tus aplicaciones utilizando las mismas herramientas centrales.
• Acceso a APIs del Sistema: Ya sea que uses CoreLocation, AVFoundation, o ARKit, ambos frameworks actúan como la capa de presentación; la lógica de negocio y el acceso al hardware subyacente de Swift sigue siendo exactamente el mismo.
• Rendimiento Nativo: Ninguno de los dos es un framework híbrido o web. Ambos compilan a código nativo altamente optimizado, utilizando Metal y CoreAnimation por debajo para garantizar animaciones fluidas a 60 o 120 fps.

3. Diferencias Clave: SwiftUI vs UIKit

Aquí es donde entramos en materia. La elección entre un framework u otro dicta cómo estructurarás tu proyecto en Xcode.

Paradigma: Imperativo vs Declarativo

Como mencionamos, esta es la diferencia más grande.

• UIKit (Imperativo): Instancias objetos (UIButton, UILabel), configuras sus propiedades, y luego mutas estas propiedades en respuesta a eventos. Utilizas Interface Builder (Storyboards o XIBs) o escribes vistas programáticamente utilizando Auto Layout.
• SwiftUI (Declarativo): Describes el UI mediante estructuras ligeras (struct) de Swift. Usas modificadores para alterar el aspecto de las vistas. La vista es simplemente una función del estado.

Gestión del Estado (State Management)

• UIKit: Utiliza el patrón de Delegación (Delegates), notificaciones (NotificationCenter), o el patrón Target-Action. Mantener sincronizado el modelo de datos con la vista puede ser un dolor de cabeza, dando lugar a los temidos controladores de vista masivos (“Massive View Controllers”).
• SwiftUI: Introduce envoltorios de propiedades (Property Wrappers) como @State, @Binding, @StateObject, y @EnvironmentObject. Cuando el valor de un @State cambia, SwiftUI invalida la vista actual y la vuelve a calcular. La sincronización es automática.

Sistema de Layout (Diseño)

• UIKit: Confía en Auto Layout, un sistema de resolución de ecuaciones matemáticas. Defines restricciones (constraints) como “el borde superior de este botón debe estar a 20 puntos de la parte inferior de esta etiqueta”. Es poderoso pero puede ser complejo y propenso a conflictos de diseño.
• SwiftUI: Utiliza un sistema basado en pilas (Stacks): VStack (vertical), HStack (horizontal) y ZStack (profundidad). Es increíblemente intuitivo y se parece más a los sistemas de diseño de la web como Flexbox, lo que acelera enormemente la maquetación en Xcode.

4. Tabla Comparativa: SwiftUI vs UIKit

Para que tengas una referencia rápida como iOS Developer, aquí tienes una tabla comparativa exhaustiva:

5. El Desarrollo Multiplataforma: iOS, macOS y watchOS

Una de las propuestas de valor más atractivas de SwiftUI para la programación Swift es su naturaleza multiplataforma. Apple lo define con el lema: “Aprende una vez, aplícalo en cualquier lugar”.

UIKit en el Ecosistema

UIKit fue diseñado exclusivamente para pantallas táctiles de iPhone e iPad.

• Si querías hacer una app para macOS, tenías que aprender AppKit, que tiene paradigmas similares pero componentes totalmente distintos (NSView en lugar de UIView).
• Para watchOS, debías usar WatchKit, que era bastante limitado y operaba de manera diferente.
• (Nota: Apple introdujo Mac Catalyst para portar apps de iPad a Mac usando UIKit, pero a menudo se sienten como adaptaciones, no como apps nativas de Mac).

SwiftUI en el Ecosistema

SwiftUI cambia las reglas del juego. Puedes construir vistas que compilan de forma nativa en todos los dispositivos de Apple usando el mismo código de Swift.

• Un Toggle en SwiftUI se renderizará como un interruptor verde estándar en iOS, pero se verá como una casilla de verificación (checkbox) clásica en macOS, y tomará la apariencia táctil adaptada para watchOS.
• Esto permite al iOS Developer convertirse en un desarrollador del ecosistema completo de Apple con una fricción mínima. Puedes compartir hasta el 90% de tu código base entre una app de iPhone y su compañera de Apple Watch.

6. Interoperabilidad: Lo Mejor de Ambos Mundos

Una preocupación común al iniciar un proyecto nuevo en Xcode es: “¿Qué pasa si SwiftUI no tiene el componente que necesito?”.

Apple fue inteligente e hizo que SwiftUI vs UIKit no fuera una batalla a muerte, sino una relación simbiótica. Puedes usar componentes de uno dentro del otro sin problemas.

Usar UIKit dentro de SwiftUI

Si necesitas usar un mapa complejo de terceros, o un componente legacy de tu empresa basado en UIKit, puedes envolverlo usando el protocolo UIViewRepresentable (o UIViewControllerRepresentable).

// Ejemplo conceptual: Envolviendo un UIActivityIndicatorView (UIKit) para usarlo en SwiftUI
import SwiftUI
import UIKit

struct SpinnerView: UIViewRepresentable {
    func makeUIView(context: Context) -> UIActivityIndicatorView {
        let spinner = UIActivityIndicatorView(style: .large)
        spinner.startAnimating()
        return spinner
    }

    func updateUIView(_ uiView: UIActivityIndicatorView, context: Context) {
        // Actualizaciones cuando cambia el estado de SwiftUI
    }
}

Usar SwiftUI dentro de UIKit

Si tienes una aplicación gigante construida en UIKit y quieres empezar a migrar pantallas usando la programación Swift moderna, puedes alojar vistas de SwiftUI usando UIHostingController.

// Ejemplo conceptual: Abriendo una vista de SwiftUI desde un UIViewController
import UIKit
import SwiftUI

class MiViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let miVistaSwiftUI = ContentView() // Tu vista hecha en SwiftUI
        let hostingController = UIHostingController(rootView: miVistaSwiftUI)
        
        // Lo añades como hijo a tu ViewController actual
        addChild(hostingController)
        view.addSubview(hostingController.view)
        hostingController.view.frame = view.bounds
        hostingController.didMove(toParent: self)
    }
}

7. Comparativa Práctica de Código

Para ilustrar mejor la diferencia entre ambos paradigmas, veamos cómo un iOS Developer crearía una simple pantalla con un botón que cuenta cuántas veces ha sido presionado.

El enfoque UIKit (Imperativo)

Requiere gestionar la vista, el controlador, el objetivo (target) y actualizar manualmente el texto.

import UIKit

class ContadorViewController: UIViewController {
    var contador = 0
    let label = UILabel()
    let boton = UIButton(type: .system)

    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .white
        
        // Configurar Label
        label.text = "Has presionado 0 veces"
        label.translatesAutoresizingMaskIntoConstraints = false
        view.addSubview(label)
        
        // Configurar Botón
        boton.setTitle("Presionar", for: .normal)
        boton.translatesAutoresizingMaskIntoConstraints = false
        boton.addTarget(self, action: #selector(incrementarContador), for: .touchUpInside)
        view.addSubview(boton)
        
        // Auto Layout Constraints (simplificado para el ejemplo)
        NSLayoutConstraint.activate([
            label.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            label.centerYAnchor.constraint(equalTo: view.centerYAnchor, constant: -20),
            boton.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            boton.topAnchor.constraint(equalTo: label.bottomAnchor, constant: 20)
        ])
    }

    @objc func incrementarContador() {
        contador += 1
        label.text = "Has presionado \(contador) veces" // Actualización Manual
    }
}

El enfoque SwiftUI (Declarativo)

El mismo resultado en una fracción del código, donde el estado gobierna la interfaz.

import SwiftUI

struct ContadorView: View {
    // El estado. Cuando cambia, SwiftUI redibuja la vista automáticamente.
    @State private var contador = 0 

    var body: some View {
        VStack(spacing: 20) { // Stack vertical para el layout
            Text("Has presionado \(contador) veces")
                .font(.headline)
            
            Button("Presionar") {
                contador += 1 // Muta el estado, la UI se actualiza sola
            }
            .buttonStyle(.borderedProminent)
        }
    }
}

Nota: Fíjate cómo en SwiftUI no tuvimos que preocuparnos de restricciones matemáticas (Constraints) ni de crear un enlace manual entre el dato contador y el texto del Text.

8. Conclusión: ¿Cuál debería elegir un iOS Developer hoy?

El debate SwiftUI vs UIKit ya tiene un claro ganador de cara al futuro, pero el presente requiere pragmatismo.

1. Si estás empezando un nuevo proyecto desde cero hoy (Greenfield): Elige SwiftUI. La velocidad de desarrollo en Xcode, la simplicidad de la programación Swift declarativa y las Live Previews te ahorrarán cientos de horas. Además, Apple está centrando todas sus nuevas APIs (como los widgets o la Dynamic Island) exclusivamente en SwiftUI.
2. Si necesitas compatibilidad con versiones antiguas (iOS 12 o inferior): Deberás usar UIKit. Sin embargo, esto es cada vez menos común dado que la adopción de las últimas versiones de iOS suele superar el 85% rápidamente.
3. Si mantienes una aplicación existente (Legacy): No reescribas todo de golpe. Utiliza la interoperabilidad. Escribe las nuevas funcionalidades y pantallas en SwiftUI e intégralas en tu aplicación UIKit usando UIHostingController.

Convertirse en un experto iOS Developer hoy implica dominar la fluidez declarativa de SwiftUI, sin olvidar cómo funciona UIKit bajo el capó, ya que seguirás encontrándote con él en librerías de terceros y bases de código maduras durante los próximos años.

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