Dos horas peleando con AirDrop: los tres errores que me desviaron

Este fin de semana pasé todo mi entorno de trabajo a una MacBook nueva. Sesenta y ocho proyectos, cuarenta y cinco bases de datos, las claves, la configuración. Terminó bien, verifiqué tabla por tabla y todo coincidía.

Entonces quise mandarme una foto desde el teléfono y ahí empezó la otra historia.

Desde la Mac veía mi iPhone en AirDrop, con su nombre y su iconito. Desde el iPhone la Mac no existía. Probé tres veces, cambié de foto, cerré y abrí el Finder, dejé el teléfono pegado a la pantalla como si eso sirviera de algo.

Lo básico salió limpio. Wi-Fi y Bluetooth encendidos, la interfaz awdl0 activa, firewall apagado, visibilidad en "todos", ningún perfil de administración instalado. Reinicié dos veces. Igual.

Así que abrí el registro del sistema, y ahí encontré carnaza. Tres mensajes que parecían la causa y no lo eran. Escribo esto porque los tres circulan en foros como si fueran el diagnóstico.

Guía: qué probar cuando AirDrop no funciona

"WiFiP2P bit is not set" no significa que AirDrop esté roto

Este mensaje aparece en el registro de sharingd, el proceso que gestiona AirDrop en macOS. La línea completa es esta:

WiFiP2P bit is not set, WiFi state: Unknown

En mi Mac averiada se repetía veintinueve veces en diez minutos. Me pareció el culpable perfecto: ese bit anuncia a los demás equipos que puedes recibir archivos por Wi-Fi directo. Y encima el sistema decía no saber el estado del Wi-Fi, teniendo IP y navegando sin problema.

Perdí un buen rato ahí. Apagué y encendí el Wi-Fi, reinicié el proceso, reinicié la máquina entera. El bit seguía sin activarse.

Lo que lo descartó: mi MacBook con macOS 26.6.2, a la que el iPhone sí ve, registra exactamente la misma línea. Nunca activa ese bit tampoco. Aparece igual con AirDrop roto que con AirDrop funcionando, así que no sirve como diagnóstico.

"Temporary self identity not found" tampoco es la causa

El segundo lleva tres almohadillas delante, que en los registros de Apple marca severidad de error:

### Temporary self identity not found

Da la impresión de que el equipo no pudo construir su identidad, cosa que explicaría muy bien por qué nadie lo ve. Me lo creí.

Lo comprobé reiniciando sharingd en la Mac sana y capturando su arranque. Escribe el mismo error, una sola vez, igual que la averiada en la misma prueba.

La línea que sí importa está dos renglones más arriba y dice Self identity: RPIdentity, Type Self, seguida de un identificador. Esa es la identidad real, y existía en las dos máquinas. La temporal que falta es otra cosa y su ausencia no rompe nada.

Los eventos "unregistered" son registro normal

Este me convenció de verdad. Conté las apariciones de la palabra "unregistered" en identityservicesd, que maneja la identidad de Apple. Cuarenta y tres en la Mac averiada. Cero en la sana. Diferencia brutal, caso cerrado, ya está.

Pues no.

Leí las líneas completas en vez de contarlas y resultaron ser estas:

Returning publicIdentity to register {publicIdentityContainer: ...}
Checking if we have unregistered KT Data that is ready to register.

Es el registro funcionando con normalidad. La palabra aparece dentro de nombres de campo. La diferencia de conteo venía del volumen: la Mac recién configurada generaba 20.636 líneas en diez minutos y la otra 3.338, porque llevaba meses tranquila.

Conté coincidencias sin leer las frases. Con el equipo en la mesa y la evidencia delante.

Lo que era: el llavero de iCloud apagado

El fallo estaba en Contraseñas y llavero, dentro de iCloud en Ajustes del Sistema. Apagado, con la cuenta de Apple iniciada y el equipo visible en la lista de dispositivos de la cuenta. Todo se veía correcto.

Sin ese interruptor, el Mac no termina de construir la identidad con la que se presenta ante tus otros equipos. El resultado es exactamente el síntoma que tenía: ve a los demás y los demás no lo ven a él.

Lo activé. Y luego, por probar, lo volví a apagar. Ahí perdí otro rato, porque al apagarlo la identidad se borra y volví al punto de partida.

Al final cerré la sesión de iCloud entera, entré de nuevo, dejé el llavero encendido, abrí Mensajes para que el equipo terminara de registrarse y reinicié. El iPhone vio la Mac a la primera.

El momento en que me sentí tonto

Tenía las dos Macs a dos metros, con el mismo Apple ID y en la misma red. Una funcionaba. Pasé hora y media interpretando registros de la averiada sin mirar ni una vez qué escribía la sana.

Cuando por fin comparé, las tres pistas se cayeron en cinco minutos.

Con hardware esto lo tengo automático. Si dudo de una batería, la pruebo en otro equipo. Si dudo de un flex, lo cambio por uno bueno y salgo de dudas. Nadie en el taller se pone a teorizar sobre una pieza teniendo otra igual al lado. Con software me costó llegar al mismo reflejo, teniendo dos máquinas casi idénticas pegadas.

Si tienes un solo equipo y no puedes comparar, el orden sensato es al revés del que seguí: revisa la sesión de Apple y el llavero primero, y deja los registros para el final.

Dos detalles sueltos que también hacen perder tiempo. La opción "todos" en AirDrop caduca sola a los pocos minutos y vuelve a contactos. Y si el iPhone tiene el Punto de Acceso Personal encendido, AirDrop se apaga del todo.

Caso propio, Quito, septiembre de 2026. MacBook Pro (Mac16,7) con macOS 27.0, build 26A428, comparada contra una MacBook con macOS 26.6.2, mismo Apple ID y misma red. Los conteos salen de log show filtrado por proceso.

Servicio técnico para Mac en Quito