Swinject: qué es, principios de Dependency Injection y cómo funciona

Qué es Swinject y Dependency Injection

Swinject es un contenedor DI de código abierto para el lenguaje Swift, diseñado para simplificar la inyección de dependencias en aplicaciones para iOS, macOS y watchOS. El framework utiliza el enfoque Service Locator: los servicios se registran en un contenedor central, y el contenedor resuelve automáticamente el grafo de dependencias cuando se solicita una instancia.

Dependency Injection (DI) es un patrón de diseño donde un objeto recibe sus dependencias desde el exterior en lugar de crearlas internamente. Esto reduce el acoplamiento entre componentes, simplifica las pruebas unitarias y permite reemplazar implementaciones sin modificar el código del consumidor.

Según Martin Fowler (2004), DI es un caso específico de Inversion of Control y se implementa mediante inyección por constructor, propiedad o método. Swinject automatiza este proceso, eliminando la necesidad de escribir fábricas y localizadores de servicios manualmente.

Use Swinject en proyectos con tres o más servicios que tengan dependencias cruzadas, donde la construcción manual de objetos genera un código de inicialización inflado y una menor capacidad de prueba.

Swinject se integra estrechamente con el ecosistema Apple y soporta todas las versiones de Swift a partir de 3.0. El framework es compatible con Objective-C mediante puentes, lo que permite introducirlo en proyectos existentes en lenguajes mixtos sin una migración completa del código. Esto es especialmente relevante para aplicaciones grandes con más de cinco años de desarrollo.

Cómo funciona el contenedor Swinject

El contenedor Swinject está implementado por la clase Container, que almacena un registro de servicios registrados. Cuando se llama al método resolve, el contenedor crea un objeto, resolviendo todas sus dependencias recursivamente a través del grafo de registros.

Container y Service

Container es el objeto central donde se registran las correspondencias entre abstracciones y sus implementaciones. Un Service es un protocolo que define un contrato, mientras que un Component es una clase que implementa dicho protocolo. El registro se realiza mediante el método register, que toma el tipo de servicio y una fábrica.

let container = Container()
container.register(Networking.self) { _ in
    NetworkService()
}
let service = container.resolve(Networking.self)

El método resolve devuelve una instancia de la implementación concreta registrada para el protocolo especificado. Si una dependencia no está registrada, el contenedor lanza un error fatal para una detección rápida del problema durante el desarrollo.

Registro y servicios nombrados

Cada registro crea una entrada con una función de fábrica y un scope seleccionado. Un mismo servicio puede tener múltiples registros con diferentes nombres, lo que permite seleccionar una implementación específica por nombre — útil para diferentes entornos (desarrollo, staging, producción).

El proceso de resolución de dependencias funciona de forma recursiva: cuando el contenedor crea una instancia de Component, analiza su inicializador y para cada parámetro llama a resolve con el tipo correspondiente. Si una dependencia también tiene sus propias dependencias, el proceso continúa hasta que todo el grafo esté completamente construido. La profundidad de anidamiento está limitada solo por la memoria disponible, pero en la práctica rara vez supera los cinco niveles.

Métodos de inyección de dependencias en Swinject

Swinject soporta tres métodos principales de inyección de dependencias, cada uno aplicable según el contexto arquitectónico.

Constructor Injection

Constructor Injection inyecta dependencias a través de parámetros del inicializador. Este es el método preferido, que garantiza que un objeto siempre esté en un estado válido desde el momento de su creación. Swinject resuelve automáticamente todas las dependencias pasadas al constructor.

class LoginViewModel {
    private let authService: AuthProtocol

    init(authService: AuthProtocol) {
        self.authService = authService
    }
}

container.register(AuthProtocol.self) { _ in
    AuthService()
}
container.register(LoginViewModel.self) { r in
    LoginViewModel(authService: r.resolve(AuthProtocol.self)!)
}

Property Injection

Property Injection inyecta dependencias mediante el establecimiento de propiedades del objeto después de la inicialización. Se utiliza cuando una dependencia es opcional o no puede pasarse a través del constructor, por ejemplo, al trabajar con Storyboard, donde el view controller se crea automáticamente. Swinject soporta la anotación @Inject para la inyección automática de propiedades en tiempo de ejecución sin una llamada explícita a resolve.

Al usar Property Injection, es importante asegurarse de que la dependencia se establezca antes del primer acceso al objeto. De lo contrario, la propiedad permanecerá como nil, lo que provocará un crash inesperado. Swinject resuelve este problema mediante el mecanismo Implicitly Unwrapped Optional y una validación estricta en la etapa de resolución del grafo de dependencias.

Method Injection

Method Injection inyecta dependencias a través de parámetros de método. Se utiliza para servicios que solo son necesarios para realizar una única operación y no deben almacenarse como estado permanente del objeto. Este es el método menos común pero útil para callbacks.

Scopes en Swinject y su propósito

ObjectScope es un mecanismo que determina el tiempo de vida de una instancia creada dentro del contenedor Swinject. El framework proporciona tres scopes integrados con la posibilidad de crear personalizados mediante ObjectScopeProtocol.

ObjectScope.graph

El scope graph es el valor predeterminado. Cada llamada a resolve crea una nueva instancia que vive solo durante la duración de la resolución del grafo de dependencias. Es una opción segura para servicios sin estado, ya que elimina las fugas de memoria por almacenamiento en caché.

ObjectScope.container

El scope container es un singleton dentro del contenedor. La instancia se crea una vez en el primer resolve y se devuelve en todas las solicitudes posteriores. Adecuado para servicios con estado compartido: caché de datos, logger, configuración de la aplicación.

ObjectScope.transient

El scope transient crea una nueva instancia en cada llamada a resolve sin almacenamiento en caché. Se utiliza para objetos ligeros que no necesitan reutilizarse — por ejemplo, módulos que manejan una solicitud HTTP específica.

Swinject en proyectos iOS

La integración de Swinject en un proyecto iOS real comienza con la inicialización del contenedor al iniciar la aplicación — en AppDelegate o la escena. Se recomienda estructurar los registros mediante Assembly: una clase o estructura separada que agrupa servicios relacionados.

Según una encuesta de Swift Developer Community (2025), el 43% de los desarrolladores iOS utilizan contenedores DI en proyectos comerciales para gestionar dependencias de la capa de red, repositorios y coordinadores de navegación. Swinject sigue siendo la solución más popular debido a su sintaxis mínima y compatibilidad con Objective-C.

Storyboard Injection es una característica única de Swinject: el contenedor inyecta automáticamente dependencias en los view controllers creados desde Storyboard sin código adicional en AppDelegate. Esto utiliza un resolver especial pasado a UIStoryboard mediante el método init(container:), que intercepta la creación del view controller e inyecta las dependencias registradas.

En proyectos grandes, Swinject se puede combinar con coordinadores de navegación: el coordinador recibe el contenedor y crea pantallas resolviendo sus dependencias mediante resolve, manteniendo un punto de configuración único para toda la escena.

La arquitectura Assembly es el patrón recomendado para organizar los registros. Cada Assembly agrupa servicios relacionados (por ejemplo, NetworkingAssembly, DatabaseAssembly) y puede depender de otros Assemblies. Al inicializar el contenedor, todos los Assemblies se cargan y registran sus servicios, proporcionando una clara separación de responsabilidades y simplificando la navegación por la configuración DI en proyectos grandes con docenas de servicios.

Para la depuración del grafo DI, Swinject proporciona la extensión SwinjectPropertyLoader, que carga la configuración desde un archivo plist, y SwinjectStoryboard — integración con storyboards mediante una versión especial de UIStoryboard. Estas herramientas son especialmente útiles al migrar un proyecto existente de la construcción manual de objetos a DI: el desarrollador puede registrar servicios gradualmente, verificando el grafo de dependencias mediante pruebas y registros de errores de resolución sin detener el desarrollo de las funcionalidades principales.

Swinject también proporciona integración con RxSwift y Combine mediante la extensión SwinjectAutoregistration para la resolución automática de dependencias basada en los tipos de parámetros del inicializador sin registro explícito de fábricas. Esto reduce la cantidad de código de registro para servicios simples: basta con llamar a container.register(ServiceProtocol.self) sin especificar una fábrica, y Swinject construirá automáticamente la fábrica basándose en la reflexión Signal proporcionada por el runtime de Swift. Este enfoque se recomienda para servicios cuyos constructores solo aceptan tipos básicos y no requieren lógica de creación compleja.