Presentamos TransloaditKit, nuestro nuevo SDK para iOS y macOS

Mark Masterson

Desarrollador para iOS y macOS · Los Ángeles, California, Estados Unidos · Mostrar bio

¡En noviembre de 2017 llegó otro SDK: nuestro SDK para iOS y macOS, TransloaditKit! Escrito en Objective-C y compatible tanto con Objective-C como con Swift, en su versión 1.0.0 incorporó funciones básicas de Transloadit y subidas reanudables mediante el protocolo tus⁠ a las aplicaciones de Apple. Planeábamos más actualizaciones para ampliar su cobertura de la API de Transloadit.

Actualización de seguridad, septiembre de 2026: Este es el anuncio del lanzamiento original, con la configuración insegura de credenciales y los ejemplos ejecutables obsoletos reemplazados. Nunca incluyas tu Auth Secret en Info.plist, en un binario de la aplicación ni en una configuración descargada por la aplicación. Mantenlo en un servidor de confianza. El servidor debe autenticar al usuario y autorizar la subida solicitada antes de aprobar cualquier Signature. Nuestra guía de Signature Authentication explica ese límite de seguridad y cómo exigir firmas en tu Workspace.

En el lanzamiento, el paquete de CocoaPods se llamaba Transloadit. La integración con Swift también necesitaba la dependencia Arcane para sortear las limitaciones de los archivos de cabecera originales. Esos detalles de configuración corresponden al lanzamiento en Objective-C; no son instrucciones para la implementación posterior en Swift. La versión 1.0.0 firmaba las solicitudes dentro del SDK con su secreto y no ofrecía ningún callback de firma externa. Trasladar ese secreto a otro archivo de configuración de la aplicación no resolvería el problema del límite de seguridad.

La versión posterior de TransloaditKit 3.5.0⁠ añadió un inicializador signatureGenerator que permite mantener el Auth Secret en tu servidor. Para esa versión, la declaración de CocoaPods es:

pod 'Transloadit', '3.5.0'

Los usuarios de Swift Package Manager pueden seleccionar exactamente la misma versión en el repositorio de TransloaditKit⁠. La siguiente función auxiliar de Swift usa la API pública de esa versión. Acepta la integración de firma existente del backend de la aplicación; no implementa un servicio de firma:

import Foundation
import TransloaditKit

func makeUploadClient(
    authKey: String,
    configuration: URLSessionConfiguration = .default,
    signatureGenerator: @escaping SignatureGenerator
) -> Transloadit {
    Transloadit(
        apiKey: authKey,
        sessionConfiguration: configuration,
        signatureGenerator: signatureGenerator
    )
}

func makeResizeStep() -> Step {
    Step(
        name: "encode",
        robot: "/image/resize",
        options: ["width": 400, "result": true]
    )
}

La integración de firma recibe los parámetros serializados exactos. Tu backend debe permitir únicamente las instrucciones de procesamiento, los destinos, los límites de archivos y el plazo de vencimiento autorizados para ese usuario; rechaza las instrucciones arbitrarias elegidas por el cliente. Firma los bytes aprobados sin volver a serializarlos. Devuelve únicamente la firma y completa el callback del SDK con éxito o error en todos los casos, incluso cuando se agote el tiempo de espera de la red.

Hay una limitación importante en 3.5.0: al crear una Assembly, se establece auth.expires en 24 horas a partir de ese momento, y el callback público de firma no puede sustituir esos parámetros. Si tu política exige una vigencia más corta, esta vía de creación no puede cumplirla. En su lugar, crea la Assembly en tu backend o usa la API de creación de Assemblies con parámetros controlados por el servidor. No aceptes silenciosamente un plazo de vencimiento más largo para que el callback se complete con éxito.

Un ejemplo rápido de creación de una Assembly

El ejemplo original mostraba una Assembly para redimensionar imágenes. Su flujo de trabajo tenía varias etapas diferenciadas:

1. Crea un Assembly Step llamado encode con el Robot /image/resize. La función auxiliar de Swift anterior expresa esa operación con el inicializador posterior Step, añadiendo un ancho de 400 píxeles y solicitando un resultado.
2. En la API original de Objective-C, crea un Assembly con los Steps y la cantidad de archivos esperada, y luego adjunta la URL del archivo local. Los fragmentos originales de Swift usaban esa misma API de Objective-C mediante su puente con Swift.
3. Registra los callbacks de finalización y estado antes de iniciar la solicitud. El antiguo assemblyCompletionBlock recibía la respuesta de creación de la Assembly, incluido assembly_ssl_url. El ejemplo asignaba esa URL antes de llamar a invokeAssembly para iniciar la subida y a checkAssembly para consultar el estado del procesamiento.
4. Gestiona por separado el progreso de la subida, la finalización del procesamiento y los errores. Recibir la URL de una Assembly no significa que sus archivos hayan terminado de subirse o procesarse.

El SDK posterior de Swift usa createAssembly y un TransloaditPoller devuelto para el flujo combinado de subida y procesamiento. Su callback de creación no es una notificación de resultado final. Las funciones auxiliares makeUploadClient y makeResizeStep anteriores solo muestran la configuración del cliente y la creación de Steps; una aplicación sigue necesitando su integración autorizada con el backend, la selección de archivos, el ciclo de vida de la subida y la gestión de resultados.

Esa separación es importante para las subidas reanudables: el protocolo tus puede reanudar una transferencia tras una interrupción, mientras que la Assembly representa el flujo de procesamiento que la rodea. Al igual que en el lanzamiento original, agradecemos las contribuciones que mejoren ambas partes de la integración. Consulta el código fuente y la documentación del SDK⁠ para conocer las API de la versión que uses.