Un print("Error al guardar") permite comprobar rápidamente si entramos en una rama del código. Pero cuando aparecen decenas de mensajes, cuesta reconstruir qué ocurrió y desde qué componente. Y si el fallo sucede en el dispositivo de otra persona, necesitamos algo más que la salida de una sesión de depuración.

Apple ofrece un sistema de registro unificado que incorpora niveles de severidad, categorías y controles de privacidad. Su API Logger, disponible desde iOS 14 y macOS 11, permite registrar información que después podemos consultar con herramientas del sistema.

Cuando una app termina inesperadamente, el código encargado de explicar qué ha pasado tiene un problema: puede estar ejecutándose dentro del mismo proceso que acaba de fallar. Si hay corrupción de memoria o recursos bloqueados, recopilar información deja de ser una operación sencilla. CrashReportExtension, disponible desde iOS 27, permite trasladar ese trabajo a una extensión que se ejecuta en otro proceso. Apple documenta este modelo en la presentación del framework.

La separación es la novedad más interesante. La app que ha fallado pasa a ser el objeto de análisis y la extensión se encarga de inspeccionarla. Esto permite organizar el diagnóstico con tipos de Swift y APIs de Foundation sin ejecutar toda esa lógica dentro de un manager en el proceso afectado. Aun así, conviene mantener la extensión sin mucha complejidad: recibir un fallo no debería implicar inicializar todas las librerías y servicios de la aplicación.

Una pantalla de recetas puede mostrar los ingredientes junto a los pasos de preparación. En una pantalla estrecha encaja mejor colocar unos debajo de otros; al abrir un dispositivo plegable (el iPhone Duo), podemos aprovechar dos columnas. Si además queda parcialmente plegado, interesa mantener el contenido a ambos lados de la bisagra.

Con iOS 27.1, SwiftUI incorpora ArrangementView para organizar dos vistas según el espacio y las condiciones del dispositivo. Declaramos el contenido principal y el secundario, y elegimos cómo se relacionan.

Generar una clave dentro del Secure Enclave protege su parte privada, pero enviar la clave pública a un servidor deja una cuestión pendiente: cómo comprobar su procedencia. Una firma válida demuestra que alguien puede utilizar la clave privada correspondiente. Por sí sola, no revela si esa clave está protegida por hardware o si se creó mediante software.

El Secure Enclave permite realizar operaciones criptográficas sin entregar la clave privada en texto claro a la aplicación. Con Security o CryptoKit podemos generar claves protegidas por este componente. Esa protección local y la verificación remota de su origen son garantías diferentes: el servidor necesita una prueba que pueda validar por su cuenta.

Una aplicación descarga la programación de un museo sin problemas, pero empieza a fallar después de renovar el certificado del servidor. En el ordenador, la web sigue abriendo. En algunos iPhone, también. La tentación es buscar una excepción que permita conectar cuanto antes, aunque el primer paso debería ser entender qué ha dejado de cuadrar.

HTTPS protege los datos durante el transporte y permite autenticar al servidor. Si eliminamos esa segunda comprobación, una conexión cifrada puede terminar enviando información a quien está suplantando nuestro servicio.