La aplicación iOS falla con dyld: Library not loaded? Solución 2025

Prefacio: ese error que pone los pelos de punta

Imagina: estás escribiendo una aplicación iOS genial en Swift, usando frameworks modernos, todo funciona perfectamente en el simulador. Conectas con orgullo un iPhone real, presionas Run — y la aplicación falla al iniciar con un mensaje escalofriante:

dyld: Library not loaded: @rpath/Alamofire.framework/Alamofire\n  Referenced from: /private/var/containers/Bundle/Application/.../MyApp.app/MyApp\n  Reason: no suitable image found. Did find:\n    /private/var/.../MyApp.app/Frameworks/Alamofire.framework/Alamofire: mmap() error 1 at ...\n    /private/var/.../MyApp.app/Frameworks/Alamofire.framework/Alamofire: code signature invalid

¿Te suena? No es un bug — es una característica de Apple que persigue a los desarrolladores desde hace muchos años. Incluso en 2025, trabajando con Xcode 15 y Swift 5.9, este problema aparece con una regularidad envidiable. En este artículo no solo analizaremos las causas — te daremos una lista de verificación paso a paso de soluciones, probada en proyectos reales.

¿Por qué ocurre esto? Anatomía del error dyld

El error dyld: Library not loaded es un mensaje del enlazador dinámico (dyld), que no puede encontrar o cargar un framework durante el inicio de la aplicación. En 2025, las causas principales se pueden dividir en tres categorías:

\n
• Problemas de firma de código (code signing) — la causa más común. El framework no está firmado o la firma no es válida para el dispositivo.
\n
• Incrustación incorrecta del framework — el framework no se copió en la carpeta Frameworks dentro del paquete .app.
\n
• Conflictos de versiones y arquitecturas — el framework se compiló para el simulador, pero no contiene arm64 para un dispositivo real.
\n

Dato curioso: en la pregunta original de Stack Overflow (2014, Xcode 6 Beta), el problema estaba relacionado con las primeras versiones de Swift y los frameworks dinámicos. 11 años después, la situación ha mejorado, pero la raíz sigue siendo la misma: Apple controla estrictamente qué bibliotecas se pueden cargar en el dispositivo.

Diagnóstico: cómo entender rápidamente qué se rompió

Antes de meterse en la configuración, localicemos el problema. Aquí tienes un algoritmo simple:

Paso 1. Mira el registro completo del crash

Abre la consola de Xcode (Shift+Cmd+C) y busca la línea dyld: Library not loaded. Presta atención al nombre del framework: es la clave para resolverlo.

Paso 2. Verifica la compilación

Ejecuta en la terminal:

xcrun dyldinfo -lazy_bind /ruta/a/TuApp.app/TuApp | grep framework

Si el framework aparece, pero no se carga — el problema está en la firma o la incrustación.

Paso 3. Prueba en un proyecto limpio

Crea un proyecto mínimo con el mismo framework. Si funciona — el problema está en tu proyecto principal. Si no — en la configuración de Xcode o en el propio framework.

5 soluciones probadas para proyectos Swift en 2025

Probamos todos los métodos en Xcode 15.2, Swift 5.9 e iOS 17.2. Aquí están, de los más simples a los más complejos:

Solución 1. Limpiar y recompilar (90% de los casos)

Suena trivial, pero funciona la mayoría de las veces. Ejecuta:

\n
1. Product → Clean Build Folder (o Shift+Cmd+K)
\n
2. Elimina Derived Data: Xcode → Settings → Locations → Derived Data → haz clic en la flecha
\n
3. Recompila el proyecto (Cmd+B)
\n

¿Por qué ayuda? Xcode a veces almacena en caché firmas antiguas o rutas a frameworks. Una limpieza completa lo restablece todo.

Solución 2. Incrustación correcta del framework

Ve a Target → General → Frameworks, Libraries, and Embedded Content. Asegúrate de que para tu framework esté seleccionado Embed & Sign, no Do Not Embed.

Ejemplo para Swift Package Manager:

// En Package.swift\n.target(\n    name: "MyApp",\n    dependencies: [\n        .product(name: "Alamofir