iOS SDK Migrations-FAQ

Diese Seite beantwortet häufig gestellte Fragen zur Migration vom älteren Appboy iOS SDK (auch bekannt als Objective-C SDK) zum Braze Swift SDK.

Warnung

Das AppboyKit (auch bekannt als Objective-C SDK) wird nicht mehr unterstützt und wurde durch das Swift SDK ersetzt. Es wird keine neuen Features, Fehlerbehebungen, Sicherheitsupdates oder technischen Support mehr erhalten—Messaging und Analytics werden jedoch weiterhin wie gewohnt funktionieren. Weitere Informationen finden Sie unter Einführung in das neue Braze Swift SDK.

Versionsunterstützung und End-of-Life

Ist das Appboy iOS SDK 4.7.0 End-of-Life?

Ja, das Appboy iOS SDK 4.7.0 (und alle 4.x-Versionen) hat das End-of-Life erreicht. Es werden keine Sicherheits- oder kritischen Fehlerbehebungen mehr bereitgestellt. Obwohl Messaging und Analytics weiterhin normal funktionieren, sollte Version 4.7.0 aus Sicherheitsperspektive als nicht unterstützt betrachtet werden.

Was ist die minimale SWIFT SDK-Version für den Produktionssupport?

Aktuelle Hauptversionen (16.x und höher) sind das Ziel für laufenden Support, Fehlerbehebungen und neue Features. Ältere Nebenversionen erhalten möglicherweise keine fortlaufende Wartung.

Kompatibilitätsbibliotheken

Werden BrazeKitCompat und BrazeUICompat für den Produktiveinsatz mit Swift SDK 17.x unterstützt?

Ja, BrazeKitCompat und BrazeUICompat werden während der Migration für den Produktiveinsatz unterstützt. Sie dienen als „Zwischenschritt“ mit minimalem Migrationsaufwand, um Ihnen den Wechsel vom Appboy SDK zum Swift SDK mit möglichst wenigen Codeänderungen zu erleichtern – nicht als dauerhafte Lösung. Obwohl sie offiziell unterstützt werden und weiterhin Fehlerbehebungen erhalten, ist beabsichtigt, langfristig von diesen Kompatibilitätsbibliotheken auf die modernen Swift-SDK-APIs umzusteigen.

Wann werden BrazeKitCompat und BrazeUICompat entfernt?

Das Swift-SDK-Team plant die Einstellung der BrazeKitCompat-Bibliothek, jedoch wurde bisher kein konkreter Zeitplan bekannt gegeben. Es wird empfohlen, die vollständige Migration auf die modernen Swift-SDK-APIs (BrazeKit, BrazeUI) zu planen, anstatt sich dauerhaft auf die Kompatibilitätsbibliotheken zu verlassen.

Verzögerte Initialisierung

Kann ich die SDK-Initialisierung verzögern, bis die Nutzer:innen-Einwilligung vorliegt?

Ja. Das Swift SDK unterstützt die verzögerte Initialisierung, was für Apps nützlich ist, die vor dem Start des SDK auf die Einwilligung der Nutzer:innen warten müssen. Rufen Sie Braze.prepareForDelayedInitialization() (optional mit einem analyticsBehavior-Parameter) frühzeitig in application(_:didFinishLaunchingWithOptions:) auf und initialisieren Sie das SDK dann später durch Aufruf des standardmäßigen Braze-Initialisierers, nachdem die Einwilligung eingeholt wurde.

Ausführliche Informationen zur Implementierung finden Sie unter Verzögerte Initialisierung einrichten.

Welche Swift SDK-Mindestversion ist für die verzögerte Initialisierung erforderlich?

Swift SDK 11.2.0 ist die Mindestversion für die verzögerte Initialisierung. Die Stabilität von Push und Deeplinks bei verzögerter Initialisierung wurde in Version 14.1.0 weiter verbessert. Swift SDK 17.0.0 liegt deutlich über beiden Schwellenwerten.

Was passiert mit Ereignissen, die vor der SDK-Initialisierung empfangen werden?

Wenn das SDK initialisiert wird, werden die in der Warteschlange befindlichen Elemente verarbeitet. Das Verhalten variiert jedoch je nach Kanal:

Wichtig

In-App-Nachrichten und Content Cards, die vor der Initialisierung empfangen werden, werden nicht garantiert zugestellt. Stellen Sie sicher, dass das SDK initialisiert ist, bevor Sie versuchen, diese Kanäle anzuzeigen.

Ressourcen-Bundles und SPM-Integration

Warum erhalte ich einen Laufzeitfehler wegen fehlendem braze-swift-sdk_BrazeUI.bundle?

Dies ist kein bekannter SDK-Bug und liegt wahrscheinlich an einer fehlerhaften Integration. Ab Swift SDK 12.0.0 enthalten statische XCFrameworks Ressourcen direkt, anstatt sich auf externe Ressourcen-Bundles zu stützen.

Welche Anforderungen gelten für SPM/Xcode/Archivierung beim Einbetten von Ressourcen?

Ab Swift SDK 12.0.0 müssen Sie Embed & Sign für die Braze XCFrameworks in Ihren Xcode-Projekteinstellungen auswählen – dies gilt sowohl für statische als auch für dynamische Varianten. Dies ist die häufigste Ursache für fehlende Bundle-Fehler beim Archivieren oder Veröffentlichen.

Wie überschreibe ich Ressourcen-Bundles für nicht standardmäßige Build-Systeme?

Für nicht standardmäßige Build-Systeme (Tuist, Bazel, Buck, CI) verwenden Sie die genehmigten Override-APIs:

• BrazeKit.overrideResourcesBundle (beachten Sie den Plural „Resources“)
• BrazeUI.overrideResourcesBundle (beachten Sie den Plural „Resources“)

Die Singularform overrideResourceBundle wurde in Swift SDK 8.1.0 als veraltet markiert und sollte nicht mehr verwendet werden.

Nutzer:innen-Identität und Push-Token

Gibt es eine Validierungscheckliste zur Bewahrung von Profilen, Gerätezuordnungen und Push-Token?

Es gibt keine offizielle migrationsspezifische Checkliste in der Dokumentation. Wir empfehlen, die folgenden Validierungsschritte durchzuführen:

1. Bestätigen Sie, dass registerDeviceToken oder die Push-Automatisierung nach der Migration korrekt eingerichtet ist.
2. Überprüfen Sie die Anzahl der push-registrierten Nutzer:innen im Dashboard vor und nach dem Rollout.
3. Prüfen Sie stichprobenartig einige spezifische externe IDs, um sicherzustellen, dass die Gerätezuordnungen intakt geblieben sind.

Garantiert changeUser, dass Push-Token dem neuen/der neuen Nutzer:in folgen?

Es gibt keine explizit dokumentierte schriftliche Garantie. Die beabsichtigte Funktionsweise ist jedoch, dass Push-Token dem Gerät folgen, nicht dem/der Nutzer:in. Der Aufruf von changeUser sollte das vorhandene Geräte-Token mit dem neuen Nutzerprofil verknüpfen. Sie sollten changeUser testen, das Dashboard überprüfen und bestätigen, dass das Token im neuen Profil erscheint, bevor Sie einen umfassenden Rollout durchführen.