TextField y compañía: formato, teclado y tecla de retorno

Todo formulario es un traductor. A un lado hay un teclado que produce cadenas sin restricción alguna; al otro, un modelo que espera un Decimal, una Date o un correo válido. SwiftUI no oculta ese abismo: te obliga a decidir en qué punto exacto ocurre la traducción, quién la hace y qué pasa cuando falla. La diferencia entre un campo que se siente nativo y uno que irrita al usuario rara vez está en el aspecto; está en si el teclado que aparece corresponde al dato pedido, en si la tecla de retorno hace lo que promete y en si el valor mal escrito se pierde o se conserva.

Texto crudo frente a valor tipado

El inicializador con text: te entrega exactamente lo que el usuario teclea: una String que cambia en cada pulsación. Tú asumes la conversión, la validación y el manejo del error. El inicializador con value:format: interpone un FormatStyle que además conforma ParseableFormatStyle: al mostrar, formatea el valor; al confirmar, intenta analizar la cadena y escribirla en el binding tipado.

struct PagoView: View {
    @State private var concepto = ""
    @State private var importe: Decimal = 0
    @State private var unidades = 1

    var body: some View {
        Form {
            TextField("Concepto", text: $concepto)
            TextField("Importe", value: $importe,
                      format: .currency(code: "EUR"))
            TextField("Unidades", value: $unidades,
                      format: .number.precision(.fractionLength(0)))
        }
    }
}

La asimetría importante es temporal. Con text: el binding se actualiza en cada tecla; con value:format: el análisis se difiere a la confirmación —perder el foco o enviar—, y si la cadena no es analizable el campo revierte al último valor válido. Ese comportamiento es deseable en importes y fechas, y desastroso si esperabas validar carácter a carácter.

El estilo de formato no es un adorno de salida: fija a la vez cómo se muestra y qué se acepta al analizar, y ambas caras dependen de la configuración regional del dispositivo. Un usuario con la coma como separador decimal escribirá coma, y .number la entenderá; el mismo texto analizado con un separador impuesto a mano fallaría.

.number.precision(.fractionLength(2))     // dos decimales siempre
.number.grouping(.never)                  // sin separador de millares
.percent                                  // el 15 por ciento se guarda como 0.15
.currency(code: divisa.rawValue)          // símbolo y decimales segun divisa

Ese detalle del porcentaje concentra buena parte de los errores de formulario: el valor almacenado y el valor mostrado no coinciden, y quien valide contra el número tecleado en lugar de contra el valor del binding acabará rechazando entradas correctas.

El teclado propone, no dispone

Los modificadores de entrada configuran la experiencia del teclado software. Ninguno de ellos restringe lo que puede llegar al binding: un teclado físico, el portapapeles, el dictado o una extensión de teclado de terceros producen cualquier carácter. Trátalos como declaraciones de intención que mejoran la ergonomía, y valida siempre en el modelo.

TextField("Correo", text: $correo)
    .keyboardType(.emailAddress)
    .textContentType(.emailAddress)
    .textInputAutocapitalization(.never)
    .autocorrectionDisabled()

Los modificadores de entrada se heredan por el subárbol, así que aplicarlos a un contenedor afecta a todos los campos que contenga. Es cómodo para desactivar la autocorrección en una sección entera de códigos, y peligroso si en esa sección hay un campo de texto libre que sí se beneficiaba de ella.

El caso de .oneTimeCode merece atención: sin él, el sistema no ofrece el código recibido por mensaje sobre el teclado, y obligas al usuario a memorizar seis dígitos y cambiar de aplicación. Es una línea de código que elimina un abandono medible.

La tecla de retorno como parte del diseño

submitLabel cambia el glifo de la tecla de retorno: .next, .done, .search, .go, .send, .join. No cambia el comportamiento, y ahí está el riesgo: la etiqueta es una promesa que tú debes cumplir en onSubmit. Prometer .next y no mover el foco es peor que no prometer nada.

TextField("Buscar", text: $consulta)
    .submitLabel(.search)
    .onSubmit { ejecutarBusqueda() }

flowchart LR
K[Teclas del usuario] --> S[Cadena en pantalla]
S --> P[ParseStrategy del FormatStyle]
P --> V[Valor tipado del modelo]
V --> F[FormatStyle al mostrar]
F --> S
S --> R[Tecla de retorno]
R --> O[onSubmit ejecuta la promesa]

onSubmit acepta un ámbito: .onSubmit(of: .text) es el predeterminado y .onSubmit(of: .search) responde solo al campo de búsqueda de searchable. Cuando anidas formularios y no quieres que un envío interior burbujee hacia el exterior, .submitScope() corta esa propagación en el subárbol que marques.

Conviene separar dos responsabilidades que a menudo se mezclan en el mismo cierre. onSubmit responde a un gesto de intención —el usuario dio por terminado el campo— y es el sitio del avance de foco o del envío. Los efectos que dependen del valor, en cambio, pertenecen a onChange sobre el estado, porque se disparan escriba el usuario con el teclado, pegue del portapapeles o rellene el sistema por autorrelleno, tres caminos de los que solo el primero pasa por la tecla de retorno.

La compañía del campo de texto

TextField casi nunca viaja solo. Sus parientes cubren dominios que él no puede modelar, y cada uno trae restricciones propias que conviene conocer antes de descubrirlas en pruebas.

SecureField("Contraseña", text: $clave)
    .textContentType(.newPassword)

TextField("Notas", text: $notas, axis: .vertical)
    .lineLimit(3...8)

TextEditor(text: $articulo)
    .frame(minHeight: 200)

SecureField desactiva por su cuenta la corrección y el historial, y con .newPassword habilita la contraseña fuerte sugerida por el sistema, siempre que el campo de identidad contiguo declare .username. El interruptor de mostrar contraseña, tan pedido en diseño, obliga a intercambiar SecureField por TextField: como son vistas de tipos distintos, SwiftUI reconstruye el subárbol y el foco se pierde, así que hay que devolverlo explícitamente tras el cambio.

Fuera de un Form, un campo suelto no dibuja fondo ni borde, y ahí es donde tiene sentido .textFieldStyle(.roundedBorder). Dentro de un Form, aplicarlo es contraproducente: añade un borde sobre la fila que el contenedor ya estaba dibujando por ti.