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 Sicherheitskorrekturen oder kritischen Fehlerbehebungen bereitgestellt. Obwohl Messaging und Analytics weiterhin normal funktionieren, sollte Version 4.7.0 aus Sicherheitsperspektive als nicht unterstützt betrachtet werden.

Was ist die Mindestversion des Swift SDK 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 langfristige Lösung. Obwohl sie offiziell unterstützt werden und weiterhin Fehlerbehebungen erhalten, ist die Absicht, letztendlich von diesen Kompatibilitätsbibliotheken auf die modernen Swift SDK APIs umzusteigen.

Wann werden BrazeKitCompat und BrazeUICompat entfernt?

Das Swift SDK-Team plant, die BrazeKitCompat-Bibliothek einzustellen, aber es wurde noch kein konkreter Zeitplan angekündigt. Es wird empfohlen, eine vollständige Migration zu den modernen Swift SDK APIs (BrazeKit, BrazeUI) zu planen, anstatt sich auf unbestimmte Zeit 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 später, indem Sie den Standard-Braze-Initializer aufrufen, 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 Robustheit 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 Messages 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 Integrationskonfiguration. Ab Swift SDK 12.0.0 enthalten statische XCFrameworks Ressourcen direkt, anstatt auf externe Ressourcen-Bundles angewiesen zu sein.

Welche SPM-/Xcode-/Archivierungsanforderungen gelten für die Ressourceneinbettung?

Ab Swift SDK 12.0.0 müssen Sie in Ihren Xcode-Projekteinstellungen Embed & Sign für die Braze XCFrameworks 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.

Nutzeridentität und Push-Token

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

In der Dokumentation existiert keine offizielle migrationsspezifische Checkliste. 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 bleiben.

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

Es gibt keine explizite schriftlich dokumentierte Garantie. Die Designabsicht 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 neu verknüpfen. Sie sollten changeUser testen, das Dashboard überprüfen und bestätigen, dass das Token im neuen Profil erscheint, bevor Sie einen Massen-Rollout durchführen.