Dynamic Type: texto que crece sin romper el layout

Cuando alguien sube el tamaño del texto en los ajustes del sistema no está expresando una preferencia estética: está declarando el único tamaño con el que puede leer. Y sin embargo, el fallo de accesibilidad más frecuente en el ecosistema de Apple no es una etiqueta ausente, es una pantalla que se desmorona en cuanto el cuerpo de texto pasa de diecisiete a cincuenta y tres puntos. La causa es casi siempre la misma y es conceptual antes que técnica: se diseñó como si el tamaño del texto fuera una constante conocida en tiempo de diseño, cuando en realidad es una variable de entorno controlada por la persona usuaria, con un rango de más del trescientos por ciento. Un layout que asume constancia donde hay variabilidad no está mal ajustado: está mal formulado.

La escala real

El sistema define doce categorías. Siete pertenecen al rango estándar, desde extra pequeña hasta triple extra grande, con la categoría grande como valor por defecto; las cinco restantes forman el rango de accesibilidad y se numeran de uno a cinco. La diferencia entre ambos rangos no es de grado sino de naturaleza: los tamaños estándar producen variaciones que un diseño razonable absorbe sin cambios estructurales, mientras que los de accesibilidad rompen deliberadamente esa suposición. En la categoría por defecto, el estilo de cuerpo mide diecisiete puntos; en la quinta categoría de accesibilidad ronda los cincuenta y tres. El factor supera el tres, y ese número es el que conviene tener en la cabeza al mirar cualquier maqueta.

En SwiftUI ese estado vive en el entorno bajo dynamicTypeSize, es un tipo comparable y expone la propiedad isAccessibilitySize, que es el punto de corte natural para decidir un cambio de estructura. La disponibilidad del valor en el entorno tiene una consecuencia práctica importante: la adaptación al tamaño no es un truco de layout ocurrido en tiempo de dibujo, es una decisión que puedes tomar declarativamente en el mismo lugar donde compones la vista.

@Environment(\.dynamicTypeSize) private var tamano

var body: some View {
    if tamano.isAccessibilitySize {
        VStack(alignment: .leading) { contenido }
    } else {
        HStack { contenido }
    }
}

Conviene desmontar de paso un malentendido extendido: limitar el rango con dynamicTypeSize(...DynamicTypeSize.accessibility1) no es una solución, es una amputación. Existen casos legítimos y estrechos —una etiqueta dentro de una gráfica cuyo espacio es geométricamente fijo, un número en una insignia— pero aplicarlo al texto de lectura equivale a decidir por la persona que no necesita ver. Si una pantalla solo funciona con un tope, el problema está en la pantalla.

Lo que escala solo y lo que no

Los estilos de texto semánticos —cuerpo, titular, título, pie, subtítulo— escalan sin que hagas nada, porque son curvas de tamaño definidas por el sistema para cada categoría, no números. Los tamaños fijos declarados con un valor de puntos no escalan jamás. Y entre ambos extremos está el caso que más gente resuelve mal: la fuente personalizada de marca, que sí puede escalar si se declara relativa a un estilo semántico y se convierte en un tamaño congelado si se declara suelta.

Text("Cuerpo").font(.body)                                  // escala
Text("Marca").font(.custom("Inter", size: 17, relativeTo: .body))  // escala
Text("Roto").font(.system(size: 17))                        // no escala nunca

Lo que no es texto tampoco escala por su cuenta, y ahí entra ScaledMetric. Un icono de veinticuatro puntos junto a un texto de cincuenta y tres se ve ridículo y deja de cumplir su función; un espaciado de ocho puntos entre líneas que ahora miden sesenta produce un bloque ilegible; un objetivo táctil dimensionado a mano deja de guardar proporción con lo que lo rodea. ScaledMetric toma un valor base y lo multiplica por el mismo factor que aplica la categoría activa, opcionalmente relativo a un estilo concreto.

@ScaledMetric(relativeTo: .body) private var iconoLado: CGFloat = 24
@ScaledMetric(relativeTo: .body) private var separacion: CGFloat = 8

HStack(spacing: separacion) {
    Image(systemName: "bell")
        .frame(width: iconoLado, height: iconoLado)
    Text("Notificaciones")
}

Los símbolos del sistema son un caso feliz aparte: si se declaran dentro de un Label o se les asigna un estilo de texto, acompañan al texto de forma automática y conservan la alineación óptica. Esa es una razón sólida para preferirlos a mapas de bits siempre que sea posible, junto con el hecho de que soportan variantes de peso que responden al ajuste de texto en negrita del sistema mediante legibilityWeight.

Layouts que aguantan

La regla estructural es que el eje de crecimiento debe estar libre. Una fila que en tamaños normales alinea etiqueta e icono horizontalmente debe convertirse en columna cuando el texto ocupa el ancho entero; una cuadrícula de tres columnas debe pasar a una; una barra de herramientas con cinco iconos y sus rótulos debe reorganizarse o mover los rótulos a un menú. SwiftUI ofrece tres herramientas de distinto nivel de abstracción para expresar esa transición sin duplicar la vista.

let disposicion = tamano.isAccessibilitySize
    ? AnyLayout(VStackLayout(alignment: .leading))
    : AnyLayout(HStackLayout(alignment: .firstTextBaseline))

disposicion {
    Text(titulo).fixedSize(horizontal: false, vertical: true)
    Spacer(minLength: 0)
    Text(valor)
}

Hay un detalle de composición que casi nadie aplica y que resuelve una familia entera de defectos: fixedSize(horizontal: false, vertical: true) le dice al texto que puede ocupar el alto que necesite aunque el padre proponga menos. Sin esa indicación, un contenedor con restricciones ajustadas comprime el texto y provoca el truncamiento silencioso; con ella, el texto empuja y el problema se traslada al layout, donde es visible y arreglable. Prefiere siempre un defecto ruidoso a uno silencioso.

flowchart TB
a[La persona cambia el tamano en Ajustes] --> b[dynamicTypeSize en el entorno]
b --> c[Estilos semanticos recalculan su altura]
b --> d[ScaledMetric escala iconos y separaciones]
c --> e{isAccessibilitySize}
d --> e
e -->|no| f[Misma estructura con mas alto]
e -->|si| g[Cambio de eje o de columnas]
f --> h[Scroll vertical siempre disponible]
g --> h

Queda una salvaguarda global que conviene adoptar como norma: cualquier pantalla que muestre texto debe poder desplazarse verticalmente. No porque se espere que lo haga en el tamaño por defecto, sino porque en la quinta categoría de accesibilidad lo hará con certeza. Una vista sin desplazamiento es una apuesta a que el contenido siempre cabrá, y esa apuesta se pierde siempre.

Probarlo el primer día

La diferencia entre los equipos que sufren con Dynamic Type y los que no es de calendario. Si la comprobación llega al final, cada arreglo es un rediseño; si el diseño se valida desde el principio en el tamaño más grande, el resultado converge sin dolor porque las decisiones estructurales se toman con la restricción puesta. La técnica concreta es invertir el orden habitual: maquetar primero en la quinta categoría de accesibilidad y comprobar después que también se ve bien en la predeterminada, y no al revés.

#Preview("AX5") {
    FichaPersona(persona: .ejemplo)
        .dynamicTypeSize(.accessibility5)
}

#Preview("Rango completo") {
    ForEach(DynamicTypeSize.allCases, id: \.self) { t in
        FichaPersona(persona: .ejemplo).dynamicTypeSize(t)
    }
}