Gestiona dependencias en iOS con Swift Package Manager.

¿Tienes utilidades y componentes en tu aplicación y buscas una forma sencilla de reutilizarlos en otras aplicaciones? En este post vamos a ver cómo podemos crear una librería para que puedas consumir estos componentes a través de Swift Package Manager.

Lo primero de todo: ¿qué es Swift Package Manager o SPM?

Swift Package Manager se publicó en 2016 completamente integrado en la nueva versión de Xcode del mismo año y nació con el objetivo de automatizar el proceso de descarga y compilado de dependencias, presentándose como una gran alternativa ante los gestores de dependencias más usados hasta entonces: CocoaPods y Carthage.

Para entender cómo funciona SPM, primero es necesario comprender algunos conceptos:

• Module: Swift organiza el código en módulos, es decir, porciones de código que resuelven un problema en particular, puede reutilizarse en otras situaciones y es por ello que requiere un cierto control de acceso (private, public…).
• Package: un paquete está compuesto de los archivos de código como tal y un pequeño fichero manifiesto llamado Package.swift, que expone cómo se llama el paquete y cómo se organiza su contenido
• Target: los paquetes están formados por uno o varios targets, que especifican un producto y dependencias a compilar.
• Product: es el elemento (o artefacto) que resulta al compilar un target. Puede tratarse de una librería, un ejecutable, etc.

Dependency: como su nombre indica, son dependencias que son requeridas por el código fuente incluido en el package. Generalmente, vienen indicadas mediante una URL local o remota y unos requisitos de versión.

Lo que hace precisamente SPM es resolver todas las dependencias de manera recursiva, es decir, cada dependencia puede tener sus propias dependencias y así sucesivamente. SPM descarga y compila todo para que el producto resultante pueda ser utilizado en cualquier sitio.

¿Necesitas Swift Package Manager en tu proyecto?

Generalmente, en aplicaciones de tamaño medio o gran tamaño se terminan creando diferentes componentes que se reutilizan a lo largo de la aplicación: elementos visuales como labels, botones, campos de texto o utilidades que se prestan a ser reutilizadas en otros proyectos como managers de red o extensiones.

Por tanto, si dispones de un conjunto de clases que crees que vas a reutilizar en otros proyectos o crees que vas a desarrollar aplicaciones con el mismo estilo visual que una existente (apps de la misma marca por ejemplo), es altamente recomendable que migres todos estos elementos a una librería contenida en un package de SPM.

Así mismo, aunque no vayas a crear una librería nueva en SPM, es muy recomendable que migres (si es posible) las dependencias que tengas actualmente en CocoaPods o Carthage a SPM ya que cuenta con numerosas ventajas respecto a lo que se viene utilizando tradicionalmente:

• Integración completa en Xcode: con SPM no necesitarás utilizar ninguna línea de comandos para instalar o actualizar dependencias en tu proyecto.
• Mejora en tiempos de compilación: no vas a necesitar ningún workspace ni vas a tener que esperar los largos tiempos de compilación que existen en, por ejemplo, CocoaPods. Los packages que necesita tu proyecto son descargados y compilados una sola vez hasta que los actualices.
• Mayor compatibilidad: algunos pods requieren de una determinada versión de CocoaPods, por lo que obliga a los desarrolladores a tenerla instalada y a que el resto de dependencias sean compatibles con ella.
• Actualizaciones automáticas: las dependencias son actualizadas automáticamente hasta la próxima versión si así lo deseas, lo que garantiza la compatibilidad y seguridad.
• Las dependencias no se incluyen en el repo de la app: a diferencia de CocoaPods, que almacena los pods en el directorio de la aplicación, con SPM es Xcode quien gestiona las dependencias internamente y no ensucia el repositorio de la aplicación con dependencias.

Creación de un nuevo package

Aunque se pueden crear packages locales, es decir, que se encuentran en el mismo equipo que la app consumidora, en este post dependeremos de un repositorio externo para referenciarnos a él.

Para ello, vamos a partir de que disponemos, por un lado, de la aplicación consumidora en un repo y por otro lado un repo vacío en el que crearemos el nuevo package.

Para ello, abrimos Xcode y a continuación abrimos el menú File / New / Package, donde nos aparecerá la siguiente ventana:

Elegimos Library, le damos un nombre y elegimos la localización de nuestro nuevo repositorio. Tras esto, nos aparecerá el package ya creado:

En esta ventana podemos ver los elementos que componen un package:

Package.swift

Es el elemento más importante del package. De hecho, para poder acceder a esta ventana de nuevo necesitaremos hacerlo a través de este fichero, ya que no existe un proyecto de Xcode como tal. Además, si no está bien definido la librería no compilará.

Generalmente, este fichero tiene la siguiente estructura Package:

let package = Package(
    name: "MyLibrary",
    platforms: [
        .iOS(.v16),
    ],
    products: [
        .library(
            name: "MyLibrary",
            targets: ["MyLibrary"]),
    ],
    dependencies: [
        .package(url: "https://github.com/airbnb/lottie-spm.git", exact: "4.4.3")
    ],
    targets: [
        .target(
            name: "MyLibrary",
            dependencies: [.product(name: "Lottie", package: "lottie-spm")],
        .testTarget(
            name: "MyLibraryTests",
            dependencies: ["MyLibrary"]),
    ]
)

En esta estructura se define:

• Nombre del package.
• Requisitos de plataforma: en este caso, la librería solo puede ser utilizada a partir de iOS 16.
• Productos que son generados: una librería y el target al que pertenece.
• Dependencias: en este ejemplo se tiene una dependencia con el package de Lottie en su versión 4.4.3.
• Targets incluidos en el package: el de la librería como tal, donde se indica qué dependencias de las expuestas más arriba son utilizadas por este target. Y otro target destinado a los tests.

Estos son los mínimos parámetros que debemos definir. Sin embargo, si necesitas conocer más sobre él puedes obtener más información en la documentación oficial de Apple

Código fuente

Pueden verse en el árbol de ficheros de la izquierda y se clasifican en archivos fuente (source) y tests.

Es importante aclarar que el código fuente es organizado por carpetas que deben coincidir con el nombre de los diferentes targets, en este caso MyLibrary.

Bajo esta carpeta, podemos incluir todos los ficheros que consideremos necesarios, siempre teniendo en cuenta el nivel de acceso que vamos a dar a cada clase. Aquellas clases y métodos que van a ser utilizadas por la app consumidora deben marcarse como Public.

Una vez que hemos añadido nuestro código fuente y vayamos implementando la librería, podremos compilar y comprobar que todo funciona perfectamente y subir los cambios a su repositorio.

Una gran ventaja es que, al trabajar con componentes SwiftUI, las previews funcionarán casi instantáneamente ya que no tiene que compilar todo el proyecto de la aplicación, sino sólo la librería.

Además, podemos crear pequeñas vistas “showcase” para mostrar el funcionamiento de los componentes que hemos creado dentro de la propia librería.

Cómo consumir el package en tu aplicación

Ahora que tenemos nuestra librería subida a un repositorio, podemos añadirla a la app consumidora de una manera muy sencilla.

Tan sólo debemos pulsar sobre nuestro proyecto, abrir la pestaña “Package Dependencies” y pulsar el botón “+”:

Se nos abrirá la siguiente ventana donde podemos elegir algunas librerías ya proporcionadas por Apple:

Sin embargo, como lo que queremos es utilizar nuestra propia librería, debemos poner la URL del repositorio en el campo de búsqueda de la parte superior izquierda.

Por ejemplo, aquí está la librería de Lottie.

Si hemos seguido todos los pasos correctamente, al poner nuestra URL en el campo de búsqueda aparecerá la librería en el listado central y sólo faltaría elegirla para que sea incluida en el proyecto:

En este ejemplo se han incluido multitud de librerías donde se han especificado diferentes números de versión, pero no sólo podemos especificar versiones, también nombres de rama, commit o tags que hayan sido subidos al repositorio de la librería. De esta forma, siempre podemos elegir exactamente qué estado de nuestra librería queremos utilizar en la aplicación.

Por último, es importante conocer el menú de Xcode destinado a los packages:

Desde este menú se puede restablecer la caché de los packages descargados, resolver sus versiones (volverlos a descargar) y, por último, actualizarlos a la última versión disponible si así lo hemos especificado en la pantalla anterior.

Conclusiones

Disponer de componentes y utilidades que pueden ser utilizados en diferentes aplicaciones nos permitirá agilizar el desarrollo, además de facilitar la gestión de estos componentes pudiendo trabajar en la app principal mientras la librería creada mantiene su propio ciclo de vida, independientemente de los avances que se hagan en la aplicación.

Swift Package Manager simplifica mucho esta tarea y se posiciona como la mejor alternativa para gestionar las dependencias en el desarrollo de aplicaciones iOS.