iPad: clases de tamaño, multitarea y el precio de estirar

Casi nadie llama al iPhone un iPad pequeño, y esa asimetría del lenguaje delata algo real: la diferencia entre ambos no es la diagonal en pulgadas sino lo que la persona espera hacer con el aparato. En el teléfono se atiende una cosa cada vez, con el pulgar, de pie y con prisa. En la tableta se compara, se arrastra, se escribe con teclado físico y se conviven dos apps a la vez porque el trabajo consiste precisamente en cruzarlas. Una app que ignora esa diferencia no falla de forma espectacular: arranca, se ve, responde. Y aun así produce una incomodidad difusa que rara vez se verbaliza como defecto y que se traduce puntualmente en abandono.

La clase de tamaño no describe un aparato

La plataforma no te ofrece una pregunta sobre el dispositivo, y no es un olvido. Te ofrece dos valores en el entorno —la clase de tamaño horizontal y la vertical— que solo pueden ser compact o regular, y que describen el espacio realmente disponible para tu vista en este instante. Un iPhone en apaisado tiene clase horizontal regular en los modelos grandes; un iPad con tu app ocupando un tercio de la pantalla tiene clase horizontal compact. La consecuencia es incómoda pero liberadora: regular no significa iPad y compact no significa iPhone. Significan, respectivamente, hay sitio y no hay sitio.

@Environment(\.horizontalSizeClass) private var ancho

var body: some View {
    if ancho == .regular {
        PanelDoble()          // hay sitio: dos cosas a la vez
    } else {
        PanelApilado()        // no hay sitio: una cada vez
    }
}

Este fragmento es correcto y, aun así, conviene desconfiar de él. Ramificar por clase de tamaño es la herramienta de último recurso, no la primera: introduce dos ramas que hay que probar, mantener y sincronizar, y sobre todo codifica una decisión que el sistema podría tomar mejor. La regla práctica que separa a los equipos que entienden la adaptación de los que la sufren es simple: ramifica cuando la estructura de la información cambia —una lista y su detalle conviven o se turnan—, nunca cuando lo único que cambia es una medida. Para las medidas hay contenedores.

La ventana dejó de pertenecerte

En el teléfono el ancho es una constante que cambia solo al rotar. En el iPad no lo es. Split View reparte la pantalla en dos apps con un separador que la persona arrastra a voluntad; Slide Over deposita una app estrecha flotando encima; Stage Manager convierte las apps en ventanas redimensionables con un ratón. En los tres casos el ancho de tu vista es una variable continua y ajena, controlada por alguien que no eres tú y que puede cambiarla mientras el usuario escribe.

flowchart TB
a[La persona arrastra el separador] --> b[Cambia el ancho de la ventana]
b --> c[La clase de tamano puede pasar de regular a compact]
c --> d[NavigationSplitView colapsa en pila]
b --> e[El layout se recalcula de forma continua]
d --> f[El estado de navegacion debe sobrevivir]
e --> f

De ahí se sigue una exigencia que muchas apps incumplen sin saberlo: el estado tiene que sobrevivir a la transición. Si tu navegación guarda índices posicionales, referencias a objetos volátiles o un booleano que significa el panel está abierto, el colapso a pila te dejará en un lugar que nadie pidió. Si guarda identificadores y una selección declarada, el sistema traduce esa selección en pantallas apiladas y de vuelta sin que tú escribas nada. Es la misma lección de siempre con ropa nueva: lo que es un valor se puede transformar, y lo que es un efecto secundario se pierde.

struct Editor: View {
    @State private var seleccion: Nota.ID?     // identificador, no objeto
    @State private var ruta: [RutaDetalle] = []  // historial representable

    var body: some View {
        NavigationSplitView {
            List(notas, selection: $seleccion) { Text($0.titulo) }
        } detail: {
            NavigationStack(path: $ruta) { Detalle(id: seleccion) }
        }
    }
}

Hay además una consecuencia de rendimiento que se nota más en tableta que en teléfono. Durante el arrastre del separador el sistema recalcula tu jerarquía muchas veces por segundo, de modo que cualquier cálculo caro colocado en el cuerpo de una vista —una ordenación, un formateo de fecha, una decodificación— deja de ser una ineficiencia teórica y se convierte en un tirón visible que la persona atribuye, con razón, a tu app.

Los síntomas del estiramiento

Una app de teléfono ampliada a tableta no produce un error, produce un olor. Conviene aprender a reconocerlo por sus manifestaciones, porque casi todas comparten una única causa: el diseño se pensó para un ancho fijo y al crecer el ancho nadie decidió qué debía crecer con él.

Ninguno de estos síntomas se cura con una condición sobre el dispositivo. Se curan expresando la intención: este texto tiene una medida máxima legible, este contenido se reparte en tantas columnas como quepan, esta hoja pide el tamaño que necesita. Cuando la intención está declarada, el ancho deja de ser un problema y pasa a ser un dato de entrada.

Text(cuerpo)
    .frame(maxWidth: 680)                       // medida legible, no ancho de pantalla

LazyVGrid(columns: [GridItem(.adaptive(minimum: 240), spacing: 16)]) {
    ForEach(tarjetas) { Tarjeta($0) }           // tantas columnas como quepan
}

.sheet(isPresented: $editando) {
    FormularioNombre()
        .presentationDetents([.medium])          // pide lo que necesita
}

Lo que la tableta añade y el teléfono no pedía

Adaptarse al ancho evita el ridículo, pero no basta para que la app parezca nacida en el iPad. Hay un conjunto de capacidades que en el teléfono son adorno y aquí son expectativa. El teclado físico convierte los atajos en el camino principal de quien trabaja rápido, y publicarlos con keyboardShortcut los inscribe además en el menú que aparece al mantener pulsada la tecla de comando. El puntero del trackpad exige realimentación al pasar por encima, que hoverEffect proporciona con el efecto correcto para cada forma. Y arrastrar y soltar deja de ser una función avanzada para volverse la manera obvia de mover algo entre dos apps abiertas a la vez.

Button("Nueva nota", action: crear)
    .keyboardShortcut("n", modifiers: .command)   // el teclado es camino principal

TarjetaNota(nota)
    .hoverEffect(.highlight)                      // el puntero necesita respuesta
    .draggable(nota)                              // arrastrar entre apps abiertas

Conviene entender por qué estas tres cosas aparecen juntas y no por casualidad. Las tres son consecuencias de una misma condición: en la tableta la app no está sola, ni en la pantalla ni en la atención de quien la usa. El teclado importa porque hay una sesión larga; el puntero importa porque hay precisión; el arrastre importa porque hay un destino fuera de tu proceso. Diseñar para iPad es, en el fondo, aceptar que dejas de ser el centro de la experiencia y pasas a ser una pieza cooperante dentro de ella.