Wi-Fi Aware conecta un ESP32-C5 al iPhone sin router

iOS 26 trae soporte para Wi-Fi Aware en iPhone 12 y modelos posteriores, lo que permite a dispositivos compatibles descubrirse, emparejarse y comunicarse de manera directa y segura. No requiere punto de acceso y no afecta la conectividad Wi-Fi del iPhone. Este recorrido muestra los pasos para configurar un dispositivo ESP y un iPhone de modo que se emparejen y conecten usando el estándar.

¿Por qué era tan difícil hasta ahora?

Establecer comunicación Wi-Fi directa entre un iPhone y un dispositivo de internet de las cosas siempre fue un proceso complejo. Una alternativa era incorporar primero el dispositivo a la red local, lo que implica múltiples pasos de descubrimiento (típicamente sobre BLE), ingreso de credenciales y aprovisionamiento. La otra era hacer que el dispositivo levantara su propio punto de acceso suave y conectarse a él. Aunque iOS simplificó ese proceso, sigue implicando que el iPhone pierda su conectividad con el punto de acceso.

Wi-Fi Aware, también conocido como Neighbor Awareness Networking (NAN), es el estándar de la Wi-Fi Alliance que llena ese vacío. Los dispositivos se sincronizan en un clúster, anuncian y descubren servicios, se emparejan si hace falta, y luego establecen un enlace de datos directo, cifrado y de alto ancho de banda entre dos pares, que abre comunicación a nivel de sockets sobre IPv6. No hay punto de acceso, no hay servidor DHCP y no hay conexión a internet involucrada.

Apple anunció el soporte en la WWDC 2025 y lo liberó con iOS 26. Su implementación convierte a Wi-Fi Aware en una interfaz concurrente, lo que significa que mientras se comunica por ese canal el iPhone no pierde su conectividad Wi-Fi. Pero la razón de peso es otra: cada iPhone reciente (iPhone 12 y posteriores) y una larga lista de iPads (iPad de 10ª generación, iPad Air de 4ª generación, iPad mini de 6ª generación y los modelos recientes de iPad Pro) lo soportan una vez actualizados a iOS 26 o iPadOS 26. La lista completa de dispositivos elegibles está en la documentación de Wi-Fi Aware de Apple.

Android soporta Wi-Fi Aware desde la versión 8.0, pero su adopción fracasó por varios motivos. Uno fue el soporte limitado de los fabricantes; otro, que la implementación de Android dejaba las convenciones de mensajería y nomenclatura a criterio de cada aplicación.

¿Qué cambia con el enfoque de Apple?

Apple tomó un camino distinto: el marco de trabajo Wi-Fi Aware de iOS esconde las perillas del protocolo y expone solo unas pocas interfaces necesarias, lo que simplifica la tarea para quien desarrolla aplicaciones. Eso estandariza tres cosas en todas las apps:

• La nomenclatura sigue DNS-SD. Un servicio se identifica con una cadena del tipo _ESP-Demo._udp, siguiendo RFC 6763 y RFC 6335, y debe declararse por adelantado en el archivo Info.plist de la aplicación.
• El emparejamiento es obligatorio y siempre usa un PIN de seis dígitos. No existe ruta de datos abierta ni seguridad basada en contraseña. iOS siempre usa Wi-Fi Aware Pairing y realiza el intercambio de claves internamente.
• El transporte es el marco Network. Una vez emparejados, la aplicación abre una conexión ordinaria mediante la interfaz NetworkConnection, sin parámetros de Wi-Fi Aware que administrar.

La versión más reciente del estándar, la v4.0, sumó soporte de emparejamiento con un protocolo de seguridad equivalente a WPA3-PSK. Apple lo adoptó y lo declaró obligatorio para la compatibilidad.

En Espressif también actualizaron sus estándares de seguridad para igualar las especificaciones más recientes y cerrar la brecha con la implementación de Apple. Un nuevo componente, wifi_aware, se construyó específicamente para eso: implementa las convenciones de nomenclatura y descubrimiento DNS-SD sobre el protocolo Wi-Fi Aware, de modo que las aplicaciones resulten compatibles con iOS sin ajustes adicionales. Para comunicación entre dos ESP o entre un ESP y Android se puede elegir cualquier estándar de seguridad, o incluso ninguno: la restricción de seguridad alta es específica de iOS.

¿Qué se necesita para partir?

Del lado del ESP hacen falta ESP-IDF v6.1 o posterior y un chip con soporte de Wi-Fi Aware, como el ESP32-C5 usado a lo largo del artículo original. El emparejamiento y la seguridad de la ruta de datos se despachan como funciones experimentales en ESP-IDF v6.1; las versiones anteriores solo soportan descubrimiento y rutas de datos abiertas, a las que un iPhone no puede conectarse.

La vía más rápida para tener un proyecto funcional es partir del ejemplo udp_server del componente. En VS Code se abre la paleta de comandos y se ejecuta ESP-IDF: Show ESP Component Registry, se busca el componente wifi_aware, se navega al ejemplo y se crea el proyecto desde ahí. Luego, en ESP-IDF: Select Project Configuration, hay que elegir la configuración de emparejamiento compatible con iOS antes de compilar y grabar.

Desde la terminal, con un entorno ESP-IDF v6.1 activado:

idf.py create-project-from-example "espressif/wifi_aware=0.1.0:udp_server"
cd udp_server
idf.py --preset ios set-target esp32c5 build flash monitor

El preajuste ios configura todos los parámetros que un iPhone requiere y genera la compilación en build_ios/. Hay que mantener --preset ios en cada flash, monitor o menuconfig posterior: sin él, idf.py cae a la carpeta build/ por defecto, que no tiene ninguna de las opciones compatibles con iOS aplicadas.

Del lado de iOS hay que clonar el proyecto de demostración y abrir ESPWiFiAwareDemo.xcodeproj en Xcode 26 o posterior, seleccionando un equipo de desarrollo y un identificador de paquete registrado a ese equipo.

Wi-Fi Aware es una capacidad gestionada: debe habilitarse para el App ID e incluirse en su perfil de aprovisionamiento antes de que la app pueda firmarse. La demostración ya declara el permiso com.apple.developer.wifi-aware con la capacidad Subscribe, pero esa declaración no otorga la capacidad al equipo de desarrollo: hay que solicitarla mediante el formulario de Apple y esperar la aprobación. La app debe correr en un dispositivo físico con iOS 26 o iPadOS 26, porque Wi-Fi Aware no está disponible en el simulador.

¿Qué pasa después del emparejamiento?

Con ambos lados corriendo, se pulsa Pair New Device en la aplicación, se elige el dispositivo ESP y se ingresa el PIN que muestra el monitor del ESP, que por defecto es 000000. Completado el emparejamiento, la app abre automáticamente un socket UDP y muestra la respuesta de eco. Los ESP emparejados aparecen en la sección Paired ESP32s y en Ajustes → Privacidad y seguridad → Accesorios del iPhone.

Las credenciales generadas en el emparejamiento persisten en el dispositivo ESP incluso después de un reinicio. Si hace falta emparejar de nuevo, en las placas ESP-DevKitC se borran las credenciales anteriores presionando el botón BOOT durante 3 segundos. En el iPhone hay que entrar al menú de accesorios y presionar Reset WLAN Identifier. Solo cuando ambos lados quedaron reiniciados es posible volver a emparejar.

El flujo completo, a nivel de interfaces, sigue este orden: el ESP inicializa Wi-Fi y el componente, registra los eventos de ruta de datos y de emparejamiento, y anuncia el servicio sobre NAN. El iPhone activa su sesión de accesorio, descubre _ESP-Demo._udp filtrando por fabricante y modelo, y envía una solicitud de arranque con teclado de PIN. El ESP rechaza cualquier método que no sea PIN, muestra el código, responde a la solicitud y fija las credenciales. Tras el saludo de seguridad, el suscriptor levanta la ruta de datos NAN, el ESP obtiene una dirección IPv6 en su interfaz NAN y enlaza un socket UDP en el puerto 3333.

Llevarlo a un proyecto propio

Para usarlo fuera del ejemplo, se agrega wifi_aware al archivo main/idf_component.yml del proyecto:

dependencies:
  espressif/wifi_aware:
    version: "^0.1.0"

Y para la configuración de ESP-IDF, se copian las opciones de Kconfig desde el sdkconfig.defaults.ios del ejemplo al sdkconfig.defaults del proyecto. El emparejamiento por PIN se configura en el servicio anunciado y esa configuración de seguridad se pasa a la de publicación:

const wa_dp_security_cfg_t security = {
    .mode = WA_SEC_PIN_PAIRING,
    .pairing = {
        .caching_enabled = true,
    },
};

const wa_publish_cfg_t pub_cfg = {
    .service_type = "ESP-Demo",
    .proto        = WA_PROTO_UDP,
    .port         = 3333,
    .security     = &security,
};

wa_session_handle_t session;
wifi_aware_advertise(&pub_cfg, &session);

El dispositivo ESP muestra el PIN y la persona lo ingresa en el iPhone. Si el producto no tiene pantalla, el PIN puede imprimirse por consola durante el desarrollo o entregarse en una etiqueta. Con caching_enabled, el teléfono puede reconectarse sin volver a emparejar; pasando use_nvs_for_caching a wifi_aware_init() esas credenciales sobreviven a un reinicio del ESP.

Los campos vendor_name, model_name y pairing_name se fijan en pairing_info dentro de wa_publish_cfg_t, y cada valor admite hasta 15 caracteres. iOS usa esos campos para identificar el accesorio y mostrar un nombre útil en la hoja de emparejamiento. El instance_name del componente no lo muestra iOS, así que conviene usar pairing_name para el nombre que verá una persona.

¿Qué significa esto para un proyecto de IoT en Chile?

El aporte concreto es que desaparece el paso de aprovisionamiento, que es donde se pierde la mayoría de los usuarios de un producto conectado. Hasta ahora, poner en marcha un sensor o un controlador propio implicaba explicarle a la persona cómo entrar a una red temporal, escribir la clave de su Wi-Fi doméstico y esperar. Ahora son seis dígitos y listo.

Para quien vende o arma equipos en la región, el punto de atención es el chip: hace falta un ESP32-C5, no sirve un ESP32 clásico ni un ESP32-S3. Y del lado del desarrollo hay un trámite que no se puede saltar, el permiso de Apple, que se solicita y se espera. Conviene iniciarlo antes de empezar a escribir código, porque es el único paso del proceso que no depende de uno.