FocusState: el recorrido del teclado y el arte de cerrarlo

Hay un momento en todo formulario en el que el usuario termina de escribir en un campo y espera algo. Si la aplicación no decide qué pasa entonces, decide el vacío: el teclado se queda, el foco se pierde, el pulgar viaja hasta el siguiente campo y el ritmo se rompe. FocusState existe para que esa decisión sea explícita y para que el recorrido por los campos sea una propiedad del diseño, no un accidente del orden en que colocaste las vistas.

El foco es un estado, no una orden

FocusState es bidireccional. Cuando el usuario toca un campo, la propiedad se actualiza sola; cuando tú le asignas un valor, el sistema mueve el foco y abre el teclado. Esa simetría es lo que permite razonar sobre el foco igual que sobre cualquier otro estado: es idempotente, se puede observar, y nil significa que nadie tiene el foco.

struct AltaView: View {
    enum Campo: Hashable { case nombre, correo, clave }

    @State private var nombre = ""
    @State private var correo = ""
    @State private var clave = ""
    @FocusState private var campoActivo: Campo?

    var body: some View {
        Form {
            TextField("Nombre", text: $nombre)
                .focused($campoActivo, equals: .nombre)
            TextField("Correo", text: $correo)
                .focused($campoActivo, equals: .correo)
            SecureField("Contraseña", text: $clave)
                .focused($campoActivo, equals: .clave)
        }
    }
}

Conviene notar que el enumerado describe campos, no vistas: dos campos que comparten componente reutilizable siguen teniendo casos distintos, y un campo que aparece condicionalmente simplemente no puede recibir el foco mientras no exista en el árbol.

Existe también la variante booleana, .focused($tecladoVisible), útil cuando hay un solo campo. Con dos o más, el enumerado opcional es superior: expresa la exclusividad mutua en el tipo, no en una convención entre varios booleanos que podrían estar activos a la vez y no deberían.

Encadenar el recorrido

El recorrido es una función del campo actual al siguiente, y el destino natural del último campo no es otro campo sino la acción de envío. Escríbelo como una transición explícita y tendrás, gratis, la documentación del formulario.

.submitLabel(campoActivo == .clave ? .done : .next)
.onSubmit {
    switch campoActivo {
    case .nombre: campoActivo = .correo
    case .correo: campoActivo = .clave
    case .clave:  campoActivo = nil; enviar()
    case .none:   break
    }
}

stateDiagram-v2
[*] --> Nombre
Nombre --> Correo: retorno con next
Correo --> Clave: retorno con next
Clave --> Cerrado: retorno con done
Cerrado --> Nombre: toque del usuario
Cerrado --> [*]: envio

Escribir la transición como un switch sobre el campo activo, y no como un índice dentro de un array de campos, tiene una ventaja que se aprecia al mantener el código: cuando alguien inserte un campo nuevo en medio, el compilador exigirá atender el caso y el recorrido no se romperá en silencio. El orden del recorrido es una decisión de producto —a veces el usuario debe pasar por un campo opcional y a veces conviene saltárselo—, y merece estar escrito en un solo lugar legible.

Dos detalles convierten esto en producción. El primero: submitLabel debe ser coherente con el destino, y por eso se calcula a partir del campo activo en lugar de fijarse por campo. El segundo: si un campo intermedio es inválido, saltar al siguiente esconde el problema; considera devolver el foco al campo defectuoso, que es exactamente lo que hace el sistema en sus propios formularios.

Cerrar el teclado con criterio

Asignar nil a la propiedad de foco cierra el teclado. Esa es la vía canónica, y todas las demás son formas de llegar a ella. Lo que distingue una aplicación cuidada de una aproximada es cuáles ofrece y cuáles evita.

Form { /* campos */ }
    .scrollDismissesKeyboard(.interactively)
    .toolbar {
        ToolbarItemGroup(placement: .keyboard) {
            Spacer()
            Button("Listo") { campoActivo = nil }
        }
    }

Presentaciones, reconstrucciones y foco de accesibilidad

El foco no sobrevive a una reconstrucción del subárbol. Si presentas una hoja, cambias de pestaña o alteras la identidad de una vista con id, el campo enfocado desaparece y con él la propiedad vuelve a nil. Eso no es un fallo: es coherencia entre el estado del foco y el árbol que lo sostiene, y conviene apoyarse en ello en lugar de pelear.

.sheet(isPresented: $mostrandoHoja) {
    HojaDeCodigo()
}
.onChange(of: mostrandoHoja) { _, presentada in
    if !presentada { campoActivo = .correo }
}

En una hoja que existe solo para escribir —un código de verificación, un campo de búsqueda— enfocar al aparecer es correcto y esperado. Hazlo dentro de un task de la propia hoja, no desde el padre: el árbol tiene que estar montado para que el sistema acepte la asignación.