Wir stellen vor: unser iOS- und macOS-SDK TransloaditKit

Mark Masterson

iOS- & macOS-Entwickler · Los Angeles, Kalifornien, USA · Bio anzeigen

Im November 2017 gab es ein weiteres neues SDK: unser iOS- und macOS-SDK TransloaditKit! Es wurde in Objective-C geschrieben und ließ sich sowohl mit Objective-C als auch mit Swift nutzen. Version 1.0.0 brachte grundlegende Transloadit-Funktionen und fortsetzbare Uploads mit tus⁠ in Apple-Apps. Wir planten weitere Updates, um die Abdeckung der Transloadit-API auszubauen.

Sicherheitsupdate, September 2026: Dies ist die ursprüngliche Ankündigung, deren unsichere Einrichtung der Zugangsdaten und veraltete ausführbare Beispiele ersetzt wurden. Hinterlegen Sie Ihr Auth Secret niemals in Info.plist, einer App-Binärdatei oder einer Konfiguration, die von der App heruntergeladen wird. Bewahren Sie es auf einem vertrauenswürdigen Server auf. Der Server muss den Benutzer authentifizieren und den angeforderten Upload autorisieren, bevor er eine Signature genehmigt. Unser Leitfaden zur Signature Authentication erläutert diese Sicherheitsgrenze und wie Sie Signaturen in Ihrem Workspace verpflichtend machen.

Bei der Einführung hieß das CocoaPods-Paket Transloadit. Die Swift-Integration benötigte außerdem die Abhängigkeit Arcane, um Probleme mit den ursprünglichen Headern zu umgehen. Diese Einrichtungsdetails gehören zur Objective-C-Version; sie sind keine Anleitung für die spätere Swift-Implementierung. Version 1.0.0 signierte Anfragen innerhalb des SDK mit dessen geheimem Schlüssel und bot keinen externen Signatur-Callback. Diesen Schlüssel in eine andere App-Konfigurationsdatei zu verschieben, würde das Problem mit der Sicherheitsgrenze nicht beheben.

Die spätere Version von TransloaditKit 3.5.0⁠ führte den Initialisierer signatureGenerator ein, mit dem das Auth Secret auf Ihrem Server bleiben kann. Für diese Version lautet die CocoaPods-Deklaration:

pod 'Transloadit', '3.5.0'

Wenn Sie Swift Package Manager verwenden, können Sie genau dieselbe Version aus dem TransloaditKit-Repository⁠ auswählen. Die folgende Swift-Hilfsfunktion verwendet die öffentliche API dieser Version. Sie übernimmt die bestehende Integration der App zur Signierung durch das Backend; sie implementiert keinen Signaturdienst:

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

Die Signaturintegration erhält die exakt serialisierten Parameter. Ihr Backend darf nur die Verarbeitungsanweisungen, Ziele, Dateigrenzen und Ablaufzeit zulassen, die für diesen Benutzer erlaubt sind; weisen Sie beliebige vom Client gewählte Anweisungen zurück. Signieren Sie die genehmigten Bytes, ohne sie erneut zu serialisieren. Geben Sie nur die Signatur zurück und schließen Sie den SDK-Callback in jedem Ausführungspfad entweder mit Erfolg oder mit einem Fehler ab, auch bei einer Netzwerk-Zeitüberschreitung.

In 3.5.0 gibt es eine wichtige Einschränkung: Beim Erstellen einer Assembly wird auth.expires auf 24 Stunden in der Zukunft gesetzt, und der öffentliche Signatur-Callback kann diese Parameter nicht ersetzen. Wenn Ihre Richtlinie eine kürzere Gültigkeit verlangt, kann dieser Erstellungsweg sie nicht erfüllen. Erstellen Sie die Assembly stattdessen in Ihrem Backend oder verwenden Sie die API zum Erstellen von Assemblies mit serverseitig kontrollierten Parametern. Akzeptieren Sie nicht stillschweigend eine längere Gültigkeit, nur damit der Callback erfolgreich abgeschlossen wird.

Ein kurzes Beispiel zum Erstellen einer Assembly

Das ursprüngliche Beispiel zeigte eine Assembly zur Größenänderung von Bildern. Ihr Ablauf umfasste mehrere getrennte Phasen:

1. Erstellen Sie einen Assembly Step namens encode mit dem Robot /image/resize. Die obige Swift-Hilfsfunktion bildet diesen Vorgang mit dem später eingeführten Initialisierer Step ab, legt eine Breite von 400 Pixeln fest und fordert ein Ergebnis an.
2. Erstellen Sie in der ursprünglichen Objective-C-API Assembly mit den Steps und der erwarteten Dateianzahl und hängen Sie anschließend die lokale Datei-URL an. Die ursprünglichen Swift-Codeausschnitte verwendeten dieselbe Objective-C-API über deren Swift-Bridge.
3. Registrieren Sie die Abschluss- und Status-Callbacks, bevor Sie die Anfrage starten. Der alte Callback assemblyCompletionBlock erhielt die Antwort auf die Erstellung der Assembly, einschließlich assembly_ssl_url. Das Beispiel wies diese URL zu, bevor es invokeAssembly zum Starten des Uploads und checkAssembly zum Prüfen des Verarbeitungsstatus aufrief.
4. Behandeln Sie den Upload-Fortschritt, den Verarbeitungsabschluss und Fehler getrennt. Der Erhalt einer Assembly URL bedeutet nicht, dass der Upload oder die Verarbeitung der zugehörigen Dateien abgeschlossen ist.

Das spätere Swift-SDK verwendet createAssembly und einen zurückgegebenen Wert TransloaditPoller für den kombinierten Upload- und Verarbeitungsablauf. Sein Callback zur Erstellung ist keine Benachrichtigung über das endgültige Ergebnis. Die obigen Hilfsfunktionen makeUploadClient und makeResizeStep zeigen nur die Client-Konfiguration und die Erstellung von Steps; eine App benötigt weiterhin ihre autorisierte Backend-Integration, Dateiauswahl, die Verwaltung des Upload-Lebenszyklus und die Ergebnisverarbeitung.

Diese Trennung ist für fortsetzbare Uploads wichtig: tus kann eine Übertragung nach einer Unterbrechung fortsetzen, während die Assembly den zugehörigen Verarbeitungsablauf abbildet. Wie bei der ursprünglichen Veröffentlichung freuen wir uns über Beiträge, die beide Teile der Integration verbessern. Informationen zu den APIs Ihrer verwendeten Version finden Sie im SDK-Quellcode und in der Dokumentation⁠.