Qué conviene saber de UIKit y qué no

La pregunta que cierra este nivel no es qué contiene UIKit, porque la respuesta es demasiado larga para ser útil, sino algo mucho más incómodo: cuánto de todo eso merece tu tiempo si tu trabajo diario transcurre en SwiftUI. La respuesta habitual de la comunidad es evasiva y consiste en decir que depende, lo cual es cierto y no ayuda. Esta lección propone en cambio un criterio explícito y defendible, construido sobre dos variables que se pueden estimar con honestidad: con qué frecuencia vas a tocar cada zona y a qué velocidad se deprecia lo que aprendas de ella. Aplicando ese criterio, el framework se parte en tres territorios de tamaño muy desigual: un núcleo pequeño que conviene dominar activamente porque lo vas a escribir, una franja intermedia que solo hay que saber leer porque la vas a heredar, y una extensión enorme que puedes ignorar por completo sin ninguna culpa, aunque siga ocupando la mitad de los tutoriales que encuentres.

Un criterio, no una lista

Las listas de temas envejecen mal y además invitan a estudiar por acumulación. Un criterio, en cambio, se aplica a lo que aún no existe. El que propongo cruza dos ejes. El primero es la frecuencia de contacto: con qué probabilidad vas a encontrarte ese concepto en un año de trabajo real, ya sea escribiéndolo, leyéndolo o depurándolo. El segundo es la tasa de depreciación: cuánto de lo que aprendas seguirá siendo cierto y transferible dentro de cinco años, aunque cambie la API concreta.

El cruce produce cuatro cuadrantes y solo tres importan. Frecuencia alta y depreciación baja es el núcleo: conceptos que tocarás a menudo y que además explican otras cosas. Frecuencia alta y depreciación alta es la zona de lectura: la vas a encontrar en código ajeno, pero memorizar sus detalles no rinde. Frecuencia baja y depreciación baja son las curiosidades ilustrativas, que se estudian por gusto cuando aparecen. Y frecuencia baja con depreciación alta es lo descartable, que es la porción más grande del framework.

flowchart TB
a[Aparece un concepto de UIKit] --> b[Lo voy a tocar este ano de verdad]
b --> c[Si y ademas explica como funciona SwiftUI: nucleo activo]
b --> d[Si pero solo en codigo heredado: territorio de lectura]
b --> e[No y ademas hay sustituto moderno: descartar]
c --> f[Estudiar hasta poder escribirlo sin buscar]
d --> g[Estudiar hasta poder leerlo y modificarlo con cuidado]
e --> h[Reconocer el nombre y seguir adelante]

Hay una tentación que este criterio neutraliza y que conviene nombrar, porque afecta sobre todo a quien estudia con disciplina: la de tratar la exhaustividad como una virtud. En un framework estable y con documentación completa, saberlo todo tiene un valor decreciente frente al coste de mantenerlo fresco. Lo que rinde no es el inventario sino la capacidad de reconstruir: si entiendes el modelo, la API concreta se busca en dos minutos.

El núcleo activo

Este territorio es más pequeño de lo que la gente teme y cabe en una tarde de repaso una vez asentado. Contiene lo que hay que poder escribir sin consultar, porque aparece cada vez que se abre un hueco de interoperabilidad o se depura una pantalla mixta.

A esas tres piezas hay que añadir cuatro más que no dan para tarjeta pero que pertenecen igualmente al núcleo. La distinción entre el marco y los límites de una vista, junto con el sistema de coordenadas y la conversión entre espacios, porque aparece en cuanto hay que posicionar algo respecto de otra cosa. Los reconocedores de gestos y su resolución de conflictos, porque es el motivo más frecuente de que un gesto de SwiftUI deje de responder dentro de una vista envuelta. El desplazamiento con sus insets y su comportamiento de ajuste automático, porque el teclado y las áreas seguras se manifiestan ahí. Y las nociones básicas de CALayer y Core Animation, porque toda vista tiene una capa detrás y porque las sombras, las esquinas, las máscaras y las animaciones implícitas viven en ese nivel y no en el de las vistas.

// El nucleo cabe en poco codigo: contencion, anclas y primer respondedor
addChild(hijo)
view.addSubview(hijo.view)
hijo.view.translatesAutoresizingMaskIntoConstraints = false
NSLayoutConstraint.activate([
    hijo.view.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor),
    hijo.view.leadingAnchor.constraint(equalTo: view.leadingAnchor),
    hijo.view.trailingAnchor.constraint(equalTo: view.trailingAnchor),
    hijo.view.bottomAnchor.constraint(equalTo: view.bottomAnchor)
])
hijo.didMove(toParent: self)
campoBusqueda.becomeFirstResponder()

Queda una pieza del núcleo que no es exactamente UIKit sino su frontera, y que por su importancia ocupa el nivel siguiente entero: los adaptadores. Envolver una vista o un controlador para usarlos en SwiftUI, y alojar SwiftUI dentro de una app imperativa, es el uso más probable que darás a todo lo anterior, y escribirlos bien exige justamente el modelo mental que has construido en estas cuatro lecciones.

El territorio de lectura

La franja intermedia es la que más desconcierta a quien llega desde SwiftUI, porque contiene tecnologías que funcionan perfectamente, que sostienen aplicaciones enormes y que sin embargo no tiene ningún sentido aprender a escribir desde cero en 2026. La actitud correcta con ellas es la de un lector competente: entender qué hace el código, poder modificarlo con seguridad, y no ampliarlo si existe alternativa moderna.

El patrón de delegado y fuente de datos encabeza la lista. Está en todas partes en el código heredado y su lógica es simple: un objeto delega decisiones en otro mediante un protocolo, con la propiedad declarada débil para evitar el ciclo de retención. Conviene reconocerlo de inmediato, porque explica la arquitectura de la mitad de UIKit y porque su versión degenerada —el controlador que es delegado de nueve cosas— es el olor característico de las pantallas que hay que refactorizar.

Junto a él van el mecanismo de objetivo y acción, con sus selectores y su naturaleza dinámica heredada de Objective-C; el centro de notificaciones como bus de eventos global; la observación de valores clave, que sigue viva en rincones del sistema; los archivos de interfaz y los guiones gráficos con sus conexiones y transiciones, que hay que saber abrir y modificar aunque no crear; y UITableView con su pareja de protocolos, que no debe usarse en pantallas nuevas pero que aparece en prácticamente cualquier proyecto anterior a 2020.

Hay finalmente un componente de esta franja que es puramente lingüístico: saber leer Objective-C lo justo para entender una cabecera, un envío de mensaje y una declaración de propiedad. No se trata de aprender el lenguaje, se trata de no quedarse bloqueado cuando el rastro de una investigación lleva a un archivo con corchetes. Media hora de familiarización rinde durante años.

Lo que puedes ignorar

El último territorio es el más grande y el más liberador. Aquí van las cosas que puedes no aprender nunca sin que tu trabajo se resienta, y decirlo explícitamente ahorra semanas.

El lenguaje de formato visual para restricciones, que fue una idea ingeniosa y hoy es una fuente de errores en cadenas de texto sin comprobación del compilador. La subclasificación manual de layouts de colección, sustituida por completo por el modelo composicional salvo en casos verdaderamente exóticos. Las operaciones por lotes coordinadas a mano, sustituidas por las instantáneas. UITableView como punto de partida de cualquier pantalla nueva. Las máscaras de autorredimensionado y el posicionamiento por marcos calculados a mano, excepto en el interior de una vista personalizada muy concreta. Las APIs retiradas hace años que aún pueblan las respuestas de foros, desde la vista web original hasta las alertas y hojas de acción antiguas. Y las transiciones de guion gráfico como mecanismo de navegación, que además de anticuadas acoplan la estructura de la app a un archivo gráfico.

Conviene añadir un matiz para no caer en el error inverso. Ignorar no significa despreciar: significa no invertir por adelantado. Si un día tu trabajo exige escribir un layout de colección a mano porque el modelo composicional no llega, lo estudiarás entonces con el modelo mental ya construido y te costará una tarde. La diferencia entre ignorar con criterio y ser ignorante es que el primero sabe que existe, sabe cómo se llama y sabe dónde buscarlo.