el reloj no estaba roto. mi iphone iba atrasado.
esta es la continuación de mi apple watch se emparejó bien. luego lo olvidó., donde terminé con "la falla está en el reloj" y "esto necesita un arreglo de watchos". no fue así. lo que lo arregló fue actualizar el iphone. este informe es cómo lo comprobé, porque no pude demostrarlo como quería, y lo que la evidencia dice y no dice.
resumen
- el mac estuvo en macos 27.2 todo el tiempo y el iphone en ios 27.0. el reloj estuvo primero en 27.0 y luego en 27.2. falló en ambas configuraciones. actualizar solo el reloj (lo primero que probé) dejó al iphone como único dispositivo atrasado.
- restablecer el reloj y emparejarlo de nuevo (mismo apple id) desde la app watch, con ios 27.0 todavía, no ayudó. device hub seguía fallando con
DeviceKitError 4002. - actualizar el iphone a ios 27.2, de modo que mac, iphone y reloj estuvieran todos en 27.2, y emparejar desde device hub funcionó. los logs de analítica del iphone cuadran: la actualización terminó a las 00:26, después del re-emparejamiento, sin más re-emparejamientos después.
- ya no puedo ver el lado de coredevice, así que la causa es una hipótesis (versiones mezcladas), no un diagnóstico. apple respondió a fb24924229 el 12 de oct pidiendo más logs; mi respuesta está abajo.
el síntoma que quedaba
tras volver a emparejar, la vista en vivo del reloj en device hub seguía fallando:
DeviceKitError errorCode 4002
"Live device view took longer than expected to connect."
el enlace iphone ↔ reloj estaba sano (el mirroring funcionaba). solo el camino mac ↔ reloj por device hub estaba muerto, que es la misma forma del bug original. nada de lo que probé en el mac lo cambió.
dónde fui a buscar
quería los logs de emparejamiento de la noche en que volví a emparejar. el log unificado del mac no tenía nada:
$ log show --last 24h --predicate 'process == "remotepairingd"' | wc -l
0
esos mensajes caducan en horas. pero el iphone guarda su propio registro, mucho más duradero: conserva archivos de diagnóstico .ips durante semanas (ajustes ▸ privacidad y seguridad ▸ analítica y mejoras ▸ datos de analítica), y devicectl puede copiarlos sin herramientas extra:
$ xcrun devicectl device info files --device <iphone> --domain-type systemCrashLogs
$ xcrun devicectl device copy from --device <iphone> --domain-type systemCrashLogs \
--source <file> --destination <path>
480 archivos, que llegan al menos hasta el 27 de septiembre. dos importaron, y un truco: el encabezado de cada JetsamEvent-*.ips registra la build del sistema en ese momento, así que un montón de archivos tipo crash se convierte en un historial de versiones.
la cronología
hora local, utc−6, todo leído del iphone:
| cuándo | qué muestran los archivos |
|---|---|
| hasta el 2 de oct, 17:19 | iphone en ios 27.0 (24A5418b) |
| 2 de oct, 22:06 → 22:41 | cambia la identidad de emparejamiento del reloj en el iphone: una carpeta ProxiedDevice-* se detiene y empieza otra |
| 2 de oct, 23:45 – 23:54 | un reporte de rendimiento del emparejamiento: activación ~11 s, emparejamiento con código y desbloqueo, sincronización inicial, sin errores |
| 3 de oct, 00:26 | iphone actualizado a ios 27.2 (24B5089g); ota_result_success |
| desde el 3 de oct, 10:27 | iphone en 27.2; la misma identidad del reloj hasta el final de los archivos, sin más re-emparejamientos |
el reloj estuvo en watchos 27.2 (24S5091f) con las dos identidades.
primero escribí que "durante todo el fallo el reloj fue más nuevo que su iphone". eso solo describe la segunda fase. el cuadro completo, según el reporte que presenté el 24 de sept y los logs de arriba:
| fase | mac | iphone | reloj | resultado |
|---|---|---|---|---|
| 24 de sept, al presentar el reporte (antes de actualizar el reloj) | macos 27.2 | ios 27.0 | watchos 27.0 | falla |
| tras actualizar solo el reloj | macos 27.2 | ios 27.0 | watchos 27.2 | falla, también tras el restablecimiento y el re-emparejamiento del 2 de oct |
| tras actualizar el iphone (3 de oct, 00:26) | macos 27.2 | ios 27.2 | watchos 27.2 | funciona |
así que la versión exacta es: los dispositivos estaban en versiones distintas en las dos fases en que falló y en la misma versión cuando funcionó.
tras la actualización, devicectl device info details en el reloj lee pairingState: paired, transportType: localNetwork, authenticationType: manualPairing, y volvió a funcionar instalar apps en él.
qué prueba esto y qué no
- prueba que las versiones estuvieron mezcladas durante todo el fallo, que el emparejamiento iphone ↔ reloj estuvo limpio y que la mejora llegó con la actualización del iphone, no con otro re-emparejamiento del reloj.
- no separa la actualización del iphone del nuevo emparejamiento por device hub que hice justo después, y no anoté si el iphone estaba por usb en ese momento. usé el mismo apple id todo el tiempo y nunca probé otro. es un solo caso y no lo repetí.
- no prueba por qué.
remotepairingdyverifyManualPairingnunca aparecen en estos archivos, así que la razón por la que el reloj pedía un pair-setup nuevo en bucle sigue sin explicarse. "el compañero y el reloj deben tener versiones iguales" es mi hipótesis de trabajo. la diría en voz alta como hipótesis. - no me dice un detalle: el cambio de identidad queda registrado a las 22:41 y el reporte del emparejamiento abarca 23:45–23:54. o hice más de un intento esa noche, o el reporte se escribe al final. los archivos no lo dicen.
errores míos en el camino
- actualizar solo el reloj. parecía lo obvio ("reprobado en watchos 27.2: mismo comportamiento") y ensanchó la brecha con el iphone.
- escribir "la falla está en el reloj" con el iphone todavía en otra build. cada control que hice comparaba el reloj con el iphone, y nunca preguntó si sus versiones coincidían. lo primero que hay que revisar en un dispositivo acompañante es la versión de su compañero.
- buscar la evidencia en el único log que caduca. el log del mac no tenía nada; el del iphone lo conservó semanas.
lo que respondió apple
el 12 de oct apple respondió en fb24924229 que el problema "parece ser una desconexión del dispositivo" (red inestable o cable degradado) y pidió logs del mac y del dispositivo tomados justo después del incidente, idealmente con el perfil de logging de coredevice en ambos lados, además de xcrun devicectl diagnose y un sysdiagnose de cada uno. feedback assistant ahora marca el reporte como "investigación completada — no se puede diagnosticar con la información actual".
nunca tuve el perfil de logging instalado ni ejecuté devicectl diagnose mientras fallaba, y el sysdiagnose del reloj que sí tomé no tiene líneas de log entre las 22:21:34 y las 22:21:48, donde se cierra el canal. lo dije en mi respuesta, junto con la red que había descartado, la tabla de versiones de arriba y el bucle de pair-setup, y que enviaré los logs del perfil y un diagnose completo si vuelve a pasar.
lo que me llevo
- comprueba que todos los dispositivos coinciden antes de depurar el protocolo. mac, iphone y reloj en la misma línea de versión. un minuto de trabajo que hice al final.
- los logs de analítica son un historial de versiones. cada encabezado de jetsam lleva la build del sistema, y
devicectl ... systemCrashLogslos saca del teléfono. - captura antes de emparejar. instala el perfil de logging de coredevice en los tres dispositivos, luego
log stream --predicate 'process == "remotepairingd" OR process == "CoreDeviceService"'a un archivo, empareja y ejecutaxcrun devicectl diagnosejusto después de un fallo. - un arreglo no es un diagnóstico. este funcionó, y sigo sin conocer el mecanismo.
enlaces
- docs/resolution.md: la cronología de arriba, los comandos y los límites, en inglés y español
- la investigación original
- kisnner26/watchos27-pairing-bug