watchOS: complicaciones y el diseño de la interacción de tres segundos

Existe un gesto que ninguna otra plataforma obliga a hacer: levantar el brazo y mantenerlo. Ese detalle físico, aparentemente trivial, es la restricción de diseño más fuerte de todo watchOS, porque impone un presupuesto que no se negocia. Un brazo levantado cansa, delata a quien lo hace en una reunión y compite con lo que la persona estuviera haciendo con esa mano. La consecuencia es que en el reloj no diseñas pantallas: diseñas respuestas a una pregunta que alguien se hizo mientras caminaba. Si la respuesta tarda más de lo que dura el gesto, la persona baja el brazo y saca el teléfono, y esa derrota no se recupera con más funciones.

El presupuesto es de tres segundos

Conviene tomar la cifra en serio y no como una metáfora. Levantar la muñeca, enfocar, comprender y actuar es una secuencia que en la práctica dispone de unos tres segundos antes de que el gesto empiece a resultar incómodo, y buena parte de ese presupuesto se consume antes de que tu código dibuje nada. De ahí se sigue una regla de diseño que suena extrema hasta que se prueba: la primera pantalla debe contener la respuesta, no el camino hacia la respuesta.

Esto invierte la jerarquía habitual. En el teléfono es razonable abrir con una lista y dejar que la persona elija; en el reloj esa lista es ya un fracaso, porque exige leer varias opciones y decidir. Lo correcto es mostrar el dato o la acción más probable y relegar el resto a un desplazamiento que la mayoría no hará.

La consecuencia estructural es que la navegación profunda deja de tener sentido. Una jerarquía de tres niveles que en el teléfono resulta cómoda, aquí consume todo el presupuesto en llegar. Por eso las apps de reloj que funcionan tienden a ser planas, con una pantalla principal que responde y, como mucho, un nivel de detalle o de ajustes al que se llega desplazando.

La complicación es la app

Hay un hecho que reordena las prioridades de cualquier equipo que llega a watchOS: la mayoría de las personas mira la esfera del reloj decenas de veces al día y abre apps unas pocas. Si tu información puede caber en una complicación, esa complicación será tu superficie principal por un margen enorme, y la app pasará a ser el lugar donde se va cuando la complicación no basta. Diseñar en el orden inverso —primero la app, la complicación después si queda tiempo— es la decisión que más veces condena a una app de reloj a la irrelevancia.

Las complicaciones se construyen con el mismo vocabulario que los widgets del sistema, lo cual tiene una implicación práctica muy conveniente: la línea temporal que alimenta un widget alimenta también una complicación, y el modelo de recarga es el mismo. Lo que cambia son las familias disponibles, adaptadas a los huecos de cada esfera, y una restricción de estilo mucho más severa.

struct EstadoEntry: TimelineEntry {
    let date: Date
    let pendientes: Int
}

struct ComplicacionPendientes: Widget {
    var body: some WidgetConfiguration {
        StaticConfiguration(kind: "pendientes", provider: Proveedor()) { entry in
            Gauge(value: Double(entry.pendientes), in: 0...20) {
                Text("Tareas")
            } currentValueLabel: {
                Text("\(entry.pendientes)")
            }
            .gaugeStyle(.accessoryCircular)
        }
        .supportedFamilies([.accessoryCircular, .accessoryCorner, .accessoryRectangular])
    }
}

Conviene entender la línea temporal como lo que es: una promesa de futuro. No dibujas el estado actual y esperas a que alguien te despierte, sino que entregas al sistema una secuencia de instantes con lo que habrá que mostrar en cada uno, y el sistema la reproduce sin tu intervención. Ese modelo es lo que permite que una complicación sea barata en energía, y también lo que castiga a quien intenta forzar actualizaciones constantes: el presupuesto de recargas es limitado, y agotarlo por la mañana significa mostrar datos viejos toda la tarde.

Corona, gestos y la ausencia del dedo cómodo

La pantalla del reloj es pequeña, pero el problema mayor no es el tamaño sino la oclusión: el dedo que toca tapa aquello que se quiere ver. Por eso la plataforma ofrece un dispositivo de entrada que ninguna otra tiene, la corona digital, que permite recorrer un rango continuo con precisión sin cubrir nada. Cualquier valor ordenado —una lista, un desplazamiento, un volumen, una cantidad— pertenece a la corona antes que a un control táctil.

@State private var minutos: Int = 5
@FocusState private var coronaActiva: Bool

Text("\(minutos) min")
    .font(.system(size: 44, weight: .semibold, design: .rounded))
    .focusable()
    .focused($coronaActiva)
    .digitalCrownRotation($minutos.doubleValor, from: 1, through: 60, by: 1)

El resto de la gramática de entrada sigue la misma lógica de no ocupar la pantalla. El toque prolongado y el deslizamiento lateral abren opciones sin ocupar espacio permanente; el doble pellizco permite confirmar la acción principal sin usar la otra mano, que es exactamente la situación en la que el reloj gana al teléfono; y la realimentación háptica sustituye a buena parte de la confirmación visual, porque una vibración se percibe sin mirar y sin coste de atención.

flowchart TB
a[La persona levanta la muneca] --> b[Complicacion visible en la esfera]
b --> c[Basta el dato mostrado]
c --> d[Baja el brazo: interaccion completa]
c --> e[Abre la app en el estado correcto]
e --> f[Una accion principal a un toque]
f --> g[Confirmacion haptica sin mirar]

El diagrama contiene la tesis completa de la lección: el camino más valioso termina antes de llegar a tu app. Y cuando no termina, la app debe abrirse ya situada en el contexto que la complicación mostraba, no en su pantalla de inicio. Una complicación que abre la raíz de la app obliga a repetir la navegación que ya se había resuelto con la mirada, y desperdicia el presupuesto justo en el punto donde la persona ya había decidido actuar.

Energía, conexión y la app que no está sola

La muñeca impone restricciones físicas que no se pueden diseñar hacia otro lado. La batería es pequeña, la pantalla se apaga sola, la conectividad puede depender de un teléfono cercano o no existir en absoluto durante una carrera, y el sistema suspende tu proceso con una agresividad que en iOS sería impensable. Ninguna de estas condiciones es un obstáculo a sortear: son el contexto que define qué app tiene sentido construir.

De ahí salen tres disciplinas concretas. La primera es que el estado debe poder reconstruirse desde disco al instante, porque tu proceso será terminado y reanudado muchas veces al día. La segunda es que el trabajo largo pertenece a las sesiones que el sistema reconoce —entrenamiento, audio, navegación— o a tareas en segundo plano con presupuesto, nunca a un temporizador optimista. La tercera es que la sincronización con el teléfono debe ser oportunista y tolerante: se envía lo que se puede cuando se puede, y la app funciona con lo último que sabe cuando no hay nadie al otro lado.

struct VistaPrincipal: View {
    @State private var modelo = Modelo.cargadaDeDisco()   // arranque instantaneo

    var body: some View {
        Resumen(modelo: modelo)
            .task { await modelo.sincronizarSiSePuede() } // oportunista, nunca bloqueante
            .onDisappear { modelo.guardar() }             // el proceso puede morir ya
    }
}

La palabra clave de ese fragmento es oportunista. Una app de reloj bien construida nunca muestra un indicador de carga como primera pantalla, porque el presupuesto de tres segundos se agota antes de que la red responda. Muestra lo último que sabe, con su antigüedad indicada si importa, y actualiza cuando llega el dato. Esta inversión —dibujar primero, refrescar después— es lo contrario de lo que se hace por defecto en el teléfono, y es la adaptación que más cambia la sensación de rapidez sin tocar una sola línea de red.

Hay además una asimetría de responsabilidades que conviene fijar desde el principio: el teléfono es el lugar donde ocurre el trabajo pesado y el reloj es el lugar donde se consulta el resultado. Descargar un catálogo completo, resolver una sincronización con conflictos o procesar imágenes son tareas que pertenecen al otro extremo, y empujar sus resultados hacia la muñeca cuesta mucho menos energía que calcularlos en ella. Cuando esa asimetría se respeta, la app de reloj resulta ligera; cuando se ignora, resulta lenta y además gasta batería, que es la única queja que un usuario de reloj expresa siempre.