Announcing our new iOS & macOS SDK: TransloaditKit

Mark Masterson

iOS & macOS developer · Los Angeles, California, USA · Show bio

There was another new SDK in town in November 2017: our iOS and macOS SDK, TransloaditKit! Written in Objective-C and usable from both Objective-C and Swift, version 1.0.0 brought basic Transloadit functionality and resumable uploads using tus⁠ to Apple apps. We planned further updates to expand its coverage of the Transloadit API.

Security update, September 2026: This is the original release announcement, with its unsafe credential setup and obsolete executable examples replaced. Never put your Auth Secret in Info.plist, an app binary, or configuration downloaded by the app. Keep it on a trusted server. The server must authenticate the user and authorize the requested upload before approving any Signature. Our Signature Authentication guide explains that boundary and how to require signatures in your Workspace.

At launch, the CocoaPods package was named Transloadit. Swift integration also needed the Arcane dependency to work around the original headers. Those setup details belong to the Objective-C release; they are not instructions for the later Swift implementation. Version 1.0.0 signed requests inside the SDK using its secret and exposed no external signing callback. Moving that secret to a different app configuration file would not fix the security boundary.

The later TransloaditKit 3.5.0 release⁠ added a signatureGenerator initializer that allows the Auth Secret to remain on your server. For that version, the CocoaPods declaration is:

pod 'Transloadit', '3.5.0'

Swift Package Manager users can select the same exact version from the TransloaditKit repository⁠. The following Swift helper uses that version’s public API. It accepts the app’s existing backend signing integration; it does not implement a signing service:

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]
    )
}

The signing integration receives the exact serialized parameters. Your backend must allow only the processing instructions, destinations, file limits, and expiry permitted for that user; reject arbitrary client-selected instructions. Sign the approved bytes without reserializing them. Return only the signature, and complete the SDK callback with either success or failure on every path, including a network timeout.

There is an important limitation in 3.5.0: Assembly creation sets auth.expires to 24 hours in the future, and the public signing callback cannot replace those parameters. If your policy requires shorter validity, this creation path cannot satisfy it. Create the Assembly on your backend or use the Assembly creation API with server-controlled parameters instead. Do not silently accept a longer expiry to make the callback succeed.

A quick example of creating an Assembly

The original example demonstrated an image-resizing Assembly. Its workflow had several distinct stages:

1. Create an Assembly Step named encode using the /image/resize Robot. The Swift helper above expresses that operation with the later Step initializer, adding a width of 400 pixels and requesting a result.
2. In the original Objective-C API, create an Assembly with the Steps and expected file count, then attach the local file URL. The original Swift snippets used that same Objective-C API through its Swift bridge.
3. Register the completion and status callbacks before starting the request. The old assemblyCompletionBlock received the Assembly creation response, including assembly_ssl_url. The example assigned that URL before calling invokeAssembly to start the upload and checkAssembly to check processing status.
4. Handle upload progress, processing completion, and failures separately. Receiving an Assembly URL does not mean that its files have finished uploading or processing.

The later Swift SDK uses createAssembly and a returned TransloaditPoller for the combined upload-and-processing flow. Its creation callback is not a final-result notification. The makeUploadClient and makeResizeStep helpers above demonstrate client configuration and Step construction only; an app still needs its authorized backend integration, file selection, upload lifecycle, and result handling.

That separation matters for resumable uploads: tus can resume a transfer after an interruption, while the Assembly represents the processing workflow around it. As with the original release, we welcome contributions that improve both parts of the integration. See the SDK source and documentation⁠ for the APIs of the version you use.