Usar la simultaneidad estructurada con el marco Network

Hola, soy Scott y estoy muy emocionado de compartir algunas mejoras que harán que tu código de red sea aún más divertido y fácil de escribir que nunca. Si nunca has escrito una línea de código de red, estás en el lugar correcto. Y si lo has hecho, tengo algunas API nuevas y emocionantes para compartir contigo. Comenzaré con cómo crear conexiones. Luego, profundizaré en el uso de esas conexiones para enviar y recibir datos.

A continuación, analizaré cómo escuchar las conexiones entrantes. Y finalmente, cubriré cómo encontrar y conectarse a otros dispositivos en tu red. Comencemos a hacer conexiones. Network Framework le permite realizar conexiones seguras, componibles y modernas en tu app. Atrás quedaron los días de sockets, sockaddrs, ioctls difíciles de recordar y operaciones de bloqueo. Network Framework tiene Conectar por nombre, lo que significa que resolverá los nombres para que no tengas que hacerlo. Una vez que resuelve ese nombre, tiene algo llamado Happy Eyeballs, que garantiza que elija de manera eficiente la dirección mejor resuelta para conectarlo dinámicamente.

La seguridad a través de TLS está incorporada, por lo que no es necesario integrar otra biblioteca, generalmente con un tipo de API completamente diferente, en tu app solo para proteger la privacidad de sus usuarios. También admite transiciones de interfaz de red y servidores proxy, lo que habilita cosas como Wi-Fi Assist y protocolos de múltiples rutas sin que tengas que hacer nada en absoluto.

Admite transportes modernos como QUIC, e incluso te permite combinar tus propios protocolos con los integrados, lo que le permite dedicar tiempo a tu lógica empresarial y a la experiencia del usuario en lugar de depurar por qué los mensajes no llegan del punto A al punto B. Para aquellos de ustedes que admiten tanto apps nativas como apps web, Network Framework también tiene un soporte sólido para WebSockets, lo que permite que un servidor brinde servicio a toda la gama de apps de clientes.

Network Framework se construyó desde cero para que fuera componible. Lo que esto significa para ti es que cuando recurras al Network Framework, serás recompensado con un conjunto familiar de API, incluso a medida que los protocolos de red evolucionen con el tiempo, mejorando el rendimiento y la privacidad. Si alguna vez has escrito código de red utilizando TCP con la API de socket BSD, sabrás que cambiar a algo como QUIC implicaría una reescritura importante. Con Network Framework, el cambio a QUIC se puede realizar durante un almuerzo de trabajo. En iOS y macOS 26, Network Framework se integra estrechamente con el sólido soporte de Swift para operaciones asincrónicas y concurrencia estructurada. Ahora, tu código de red se integrará perfectamente con el resto de tu código Swift, lo que hará que tus apps sean más fáciles de crear y mantener. Para aquellos que son nuevos en la conexión de redes, presentaré algunos conceptos en este ejemplo que pueden resultarles desconocidos, pero no se preocupen, todo tendrá sentido al final.

Digamos que estás escribiendo tu app y quieres hablar con un servidor en www.example.com en el puerto 1029. Deseas utilizar TLS y solo deseas realizar esta conexión en una red sin restricciones. Tu punto final es donde quieres conectarte. Tu pila de protocolos determina cómo deseas conectarte. Sus parámetros lo ayudan a refinar cómo llegar allí.

Combina estos para crear una NetworkConnection. Veamos un ejemplo de cómo funciona esto en la práctica.

Establezco una conexión inicializando mi NetworkConnection con el punto final y la pila de protocolos que quiero. En este ejemplo, especifico que mi pila de protocolos es TLS. Ten en cuenta que TCP e IP se me deducen. Solo tengo que especificarlos si quiero personalizar algo, pero los valores predeterminados son buenos casi todo el tiempo.

Cuando quiero modificar los valores predeterminados, todavía lo hago de forma declarativa. Voy a desactivar la fragmentación de IP para esta conexión como ejemplo.

Primero, necesito especificar los protocolos TCP e IP debajo de TLS. Y luego, puedo personalizar las opciones que están configuradas para IP para desactivar la fragmentación.

Si alguien habilita el modo de datos bajos para minimizar el uso de la red, quiero modificar el comportamiento de mi conexión para que prohíba el uso de esas interfaces de red restringidas.

Actualizo el código para poder modificar los parámetros para la conexión porque ya no usaré los parámetros predeterminados que se crearon para mí automáticamente.

La pila de protocolos sigue siendo la misma, pero agrego mis parámetros personalizados, lo que me permite especificar que, para esta conexión específica, me gustaría que Network Framework solo considere el uso de interfaces de red que no estén en modo de datos bajos. ¡Genial! Y con el mismo estilo declarativo que ha hecho que SwiftUI sea tan popular, ahora mi código de red tiene una sensación similar a mi código de interfaz de usuario.

Si bien sería fantástico si la red estuviera siempre disponible, las condiciones de la red cambian constantemente. A diferencia de los sockets, NetworkConnection responderá a estos estados cambiantes por ti.

Cuando se inicia tu conexión, pasará al estado de preparación mientras se realizan los protocolos de enlace. Y cuando estos estén completos, pasará al estado listo. Si no hay conectividad, la conexión pasará del estado de preparación al de espera.

Cuando Network Framework detecta que las condiciones de la red han cambiado, volverá a la preparación mientras intenta conectarse al punto final remoto. Cuando tu conexión esté lista, podrá enviar y recibir datos.

Una vez que tu conexión esté en estado listo, si encuentra un error o se pierde la conectividad, pasará al estado fallido con un error para informarte lo que sucedió.

Salir o cancelar la tarea asociada con la conexión la moverá al estado cancelado. Lo bueno de esto es que no necesitas estar atento a ninguno de los estados de conexión si no lo deseas. Puedes llamar para enviar y recibir, y NetworkConnection esperará hasta que tu estado esté listo para completar esas operaciones. Pero si deseas saber en qué estado se encuentra tu conexión, tal vez para actualizar tu interfaz de usuario, puedes instalar un controlador que se llamará cuando tu conexión cambie de estado. Bien, ahora ya sabes cómo hacer una conexión. Entonces comencemos a usarlo para enviar y recibir datos en la red.

Enviar y recibir son funciones asincrónicas y ambas iniciarán la conexión si aún no se ha iniciado.

Enviar toma un objeto de datos y suspende la tarea hasta que Network Framework haya procesado los datos.

Tanto TLS como TCP son protocolos de transmisión, por lo que cuando recibes datos debes especificar cuántos bytes deseas. En este ejemplo, estoy especificando exactamente la cantidad de bytes que quiero leer. Recibir devuelve una tupla de contenido y metadatos, pero en este ejemplo, especifico que solo quiero el contenido.

Ambas funciones generarán errores si la conexión encuentra un error. Por ejemplo, si se pierde la red porque el Modo Avión está activado, puedes usar el error asociado para explicar por qué se interrumpió la transferencia. A veces no se sabe cuántos bytes de datos recibir. En este ejemplo, estoy cargando una imagen de la red. Un entero de 32 bits que recibo en mi conexión me indica cuántos bytes de datos de imagen quedan por recibir. Usando ese valor, llamo a Recibir repetidamente hasta que la imagen esté completa.

En el último ejemplo, utilicé la versión de Recibir que especifica un número exacto de bytes. En este ejemplo, uso la versión de Recibir que me permite especificar un número mínimo y máximo de bytes a recibir. Hacerlo de esta manera permite que el código analice la imagen a medida que los bytes llegan desde la red y no tenga que esperar todo el proceso. Los protocolos de flujo de bytes como TLS son excelentes, pero a menudo querrás enmarcar los bytes que envías y recibes, de modo que trabajas con mensajes en lugar de bytes. En el ejemplo donde descubrí qué tan grande era la imagen leyendo un valor de 32 bits del flujo de bytes antes del contenido de la imagen, eso enmarcaba la imagen con la longitud para diferenciarla de las imágenes vecinas. Tuve que hacer esto porque los protocolos de transmisión no preservan los límites de los mensajes. Lo que esto significa es que la cantidad de bytes pasados a una operación de envío individual no será necesariamente la cantidad de bytes pasados desde las operaciones de recepción en el otro extremo de la conexión. Por ejemplo, si llamas a Enviar con tres fragmentos de datos, el otro lado podría recibirlos un byte a la vez, todos a la vez o cualquier valor intermedio. Esto puede complicar significativamente la escritura de apps robustas y en red.

Afortunadamente, Network Framework puede ayudar. Una novedad en iOS y macOS 26 es un enmarcador de tipo, longitud, valor o TLV integrado que enmarca los mensajes para que lo que envías en un extremo de una conexión sea exactamente lo que recibes en el otro extremo.

TLV es un protocolo de mensajes simple que codifica un tipo, que puede utilizarse para describir los datos contenidos en el mensaje, y una longitud, que es el tamaño de los datos en el mensaje. A continuación se muestra el contenido real del mensaje. Los protocolos de red comunes utilizan TLV, por lo que es posible que este sea un formato que tu servidor ya hable. Vamos a probarlo. Para este ejemplo, voy a enviar y recibir tipos de mensajes de juego. GameMessage es una enumeración que usaré como tipo de mensaje. El contenido del mensaje será un personaje del juego o un movimiento del juego. Agregar TLV es tan simple como agregarlo a mi pila de protocolos. Dado que TLV enmarcará mis mensajes por mí, la interfaz para enviar y recibir es ligeramente diferente.

Voy a codificar mi estructura GameCharacter usando JSONEncoder y enviarla. Tenga en cuenta que estoy especificando el tipo de mensaje junto con los datos codificados. Ahora veamos cómo recibo mensajes usando TLV.

A diferencia del ejemplo anterior que utiliza protocolos de flujo de bytes, cuando uso TLV, no tengo que especificar la cantidad de bytes a recibir porque TLV analizará el mensaje por mí. Como quiero saber el tipo de mensaje que recibí, recibí la tupla del contenido y los metadatos asociados al mensaje. Para TLV, los metadatos incluyen el tipo. Utilizo el tipo para determinar qué tipo de contenido recibí y, utilizando esa información, descodifico los datos e imprimo lo que recibí. Esto es realmente poderoso, especialmente cuando interopera con servidores y protocolos existentes que no controlo. Ahora tengo mis bytes enmarcados sin demasiados problemas y puedo enviar y recibir mensajes. Esta es una mejora interesante respecto del uso directo de protocolos de flujo de bytes.

¿Pero qué pasaría si pudiera enviar mis objetos directamente? Una novedad en iOS y macOS 26 es la compatibilidad con el envío y la recepción directos de tipos codificables, lo que puede ayudar a simplificar parte de este código repetitivo.

Puedo contraer el personaje y mover estructuras dentro de la enumeración GameMessage. Coder es un protocolo que puedo agregar a mi pila de protocolos que enmarcará los mensajes por mí y me permitirá enviar y recibir tipos codificables sin tener que serializarlos y deserializarlos yo mismo. En este código, estoy enviando GameMessages de un lado a otro. Entonces inicializaré el codificador con el tipo que estoy enviando y recibiendo y con cómo quiero que el codificador formatee los datos. Network Framework tiene soporte integrado para formatos JSON y de listas de propiedades. Elegiré JSON para este ejemplo. Ahora puedo enviar GameMessages sin tener que realizar ninguna codificación yo mismo.

Al llamar a receive en mi conexión, se devolverá un GameMessage directamente, sin tener que hacer ninguna decodificación intermedia para pasar de un objeto de datos a un objeto GameMessage. Ahora puedo enviar y recibir GameMessages sin hacer ningún trabajo extra. Puedo concentrarme en la lógica empresarial y la interfaz de usuario de mi app sin saturarlas con un montón de código de red personalizado.

Ahora ya sabe cómo crear una conexión a un punto final y enviar y recibir datos en la conexión. Aprendiste sobre protocolos de flujo de bytes como TCP y TLS y cómo agregar protocolos de trama a tu pila de protocolos para trabajar con mensajes en lugar de flujos de bytes. ¿Pero qué pasa con las apps que escuchan conexiones entrantes?

Las conexiones entrantes son manejadas por NetworkListener. Al igual que NetworkConnection, lo inicializo declarando una pila de protocolos. A diferencia de una conexión, un oyente no tiene un método de envío o recepción.

Esto se debe a que un oyente escucha nuevas conexiones y luego las entrega al llamador. NetworkListener tiene un método de ejecución que entregará nuevas conexiones al controlador que se pase. Veamos cómo funciona. Creo mi NetworkListener de forma declarativa especificando una pila de protocolos. En este ejemplo, mis conexiones entrantes podrán enviar y recibir objetos GameMessage cifrados por TLS.

Al llamar a run en NetworkListener se comenzarán a entregar nuevas conexiones entrantes al controlador que pasé a run.

NetworkListener iniciará una nueva subtarea para cada nueva conexión. De este modo, puedo realizar operaciones asincrónicas en mi cierre sin preocuparme de que estaré impidiendo que el oyente continúe enviando nuevas conexiones entrantes. Cuando obtengo una nueva conexión, uso la propiedad de mensajes en NetworkConnection para manejar los mensajes entrantes del cliente. Ahora he creado una NetworkConnection a un punto final que ya tenía y he codificado para escuchar nuevas conexiones. Pero ahora quiero crear una NetworkConnection cuyo punto final no conozco de antemano. NetworkBrowser me permite descubrir puntos finales que puedo usar cuando creo mis conexiones. Una novedad de este año en iOS 26 es Wi-Fi Aware, una tecnología de red peer-to-peer multiplataforma que te permitirá descubrir y conectarte a una amplia gama de dispositivos compatibles. Puedes utilizar el marco DeviceDiscoveryUI para buscar y emparejarte con dispositivos cercanos mediante Wi-Fi Aware. Alternativamente, puedes buscar servicios anunciados en Bonjour. Para obtener más información sobre Wi-Fi Aware, ve "Optimiza la conectividad de tus dispositivos con Wi-Fi Aware". Para encontrar dispositivos en tu red, ya sea cerca con Wi-Fi Aware o a través de Bonjour, usa NetworkBrowser. NetworkBrowser toma descriptores de navegación, que describen lo que estás intentando encontrar. Al igual que NetworkConnection, también acepta parámetros que describen cómo deseas encontrarlo. Pero a diferencia de NetworkConnection y NetworkListener, NetworkBrowser no toma una pila de protocolos. Esto se debe a que el único trabajo de NetworkBrowser es devolver puntos finales que se pueden usar para realizar conexiones.

En este ejemplo, creo mi NetworkBrowser para buscar dispositivos cercanos utilizando el servicio Wi-Fi Aware, Tic-Tac-Toe. Al llamar a run en el navegador se iniciará y comenzará a exponer conjuntos de puntos finales al controlador que pasé para ejecutar.

En mi app, no tengo preferencia sobre qué punto final usar, por lo que elijo el primer punto final que se devuelve desde el navegador. Devolver .finish con el punto final hará que el navegador deje de ejecutarse y que el punto final regrese de la ejecución. Luego puedo usar ese punto final para inicializar una NetworkConnection exactamente de la misma manera que usé un punto final para inicializar una NetworkConnection en los ejemplos anteriores. Sin embargo, lo bueno de este punto final es que el navegador lo descubrió por mí, por lo que no tuve que saberlo de antemano.

Con todos estos nuevos protocolos, quizás te preguntes cómo elegir qué protocolo usar en tu app. Esa es una buena pregunta. La respuesta no es tan complicada como te podrías imaginar. Si estás hablando con tu propia app en otro dispositivo, no puedes equivocarte, la elección del protocolo ya está hecha. Por ejemplo, podrías estar hablando con una impresora a través de IPP sobre TCP. Si estás hablando con tu propia app en otro dispositivo, no puedes equivocarte con Coder en lugar de TLS o QUIC.

Ten en cuenta que si estás realizando una red HTTP y actualmente utilizas URLSession, no necesitas cambiar ninguno de tus códigos. Y si estás usando la API C de Network Framework o estás trabajando en Swift y prefieres usar controladores de finalización, tampoco necesitas cambiar nada de tu código. Seguirás obteniendo soporte de conexión por nombre de primera clase, componibilidad, movilidad y seguridad incorporada siempre que utilices URLSession o Network Framework en cualquier forma.

Hagamos un rápido resumen. Las novedades en iOS y macOS 26 son NetworkConnection, NetworkListener y NetworkBrowser. Aprendiste a utilizar una NetworkConnection con trama TLV y soporte para enviar y recibir tipos codificables con el protocolo Coder. NetworkListener se puede utilizar para escuchar conexiones entrantes. Además, se puede utilizar NetworkBrowser para buscar puntos finales en la red. Todo esto hace que escribir apps en red sea más fácil que nunca. ¡Eso es todo! Estas nuevas API están diseñadas desde cero para la concurrencia estructurada de Swift. Se crean de forma declarativa, de forma muy similar a cómo se diseña una interfaz de usuario en SwiftUI. Se ejecutan en tareas y se cancelarán automáticamente cuando se cancele la tarea en la que se están ejecutando. Prueba estas nuevas API para aprovechar al máximo la concurrencia estructurada en Swift, hacer que tu código sea más limpio y eliminar toneladas de texto repetitivo. Todo esto con el mismo poder y flexibilidad que Network Framework te brinda para utilizar en tus apps. Gracias por ver este video.