Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Viele Entwickler unzufrieden mit iCloud und CloudKit – Erfahrungen aus MacStammbaum und Lösungsmöglichkeiten

Aktuell beschweren sich viele Entwickler über Probleme mit unzuverlässigen Sync-Vorgängen über Apples iCloud. Besonders das CloudKit-Framework und -Server scheinen hierbei vielen Entwicklern und Anwendern Kopfzerbrechen zu bereiten.

Apple führte den CloudKit-basierten Sync zuerst bei einem eigenen Projekt ein – nämlich bei der iCloud Photo Library. Das CloudKit-Framework ist komplett auf Sync-Funktionalitäten ausgelegt und erlaubt seit 2016 auch, dass mehrere Personen gemeinsam an einem Datensatz arbeiten. Der grundsätzliche Prozess ist recht simpel: Ein Gerät lädt Datensätze hoch – und andere Geräte des Nutzers werden benachrichtigt, dass neue Inhalte zum Download bereitstehen und können diese daraufhin herunterladen. Auf diese Art und Weise ist es möglich, Datensätze über Gerätegrenzen hinweg synchron gehalten werden. Nach und nach migrierte Apple viele Dienste auf CloudKit – unter anderem iCloud Drive, die Notizen-App und Erinnerungen.


Einige Entwickler berichten nun, dass seit Frühjahr 2021 viele Anwender mit dubiosen Fehlermeldungen konfrontiert sind – obwohl die Programmierer keine Änderungen am CloudKit-Synchronisationscode durchgeführt haben. Führt eine App eine Anfrage an CloudKit durch, antworten die Apple-Server oftmals mit einer recht generischen Fehlermeldung: "503 – Service unavailable" (503 – Dienst nicht verfügbar).

Erfahrungen aus MacStammbaum und MobileFamilyTree
MacStammbaum wie auch die iOS/iPadOS-Version MobileFamilyTree setzen CloudKit ein, um Nutzern das Synchronisieren und die Zusammenarbeit mit anderen Nutzern zu ermöglichen. Auch wir beobachteten im Frühjahr 2021, dass sich vermehrt Nutzer mit dieser Fehlermeldung an den Kundensupport wendeten. Apple scheint zu dieser Zeit eine (natürlich undokumentierte) Änderung durchgeführt zu haben, welche sich auf viele Apps mit CloudKit-Unterstützung auswirkt:

Zu viele Anfragen
Lädt eine App viele Einträge zu CloudKit hoch oder lädt sehr oft Änderungen herunter, will Apple die App "einbremsen". Normalerweise sollte Apple hier den Fehlercode "CKErrorRequestRateLimited" an die App schicken – samt einer Angabe, wie lange die App mit neuen Anfragen warten soll. Dies war auch in der Vergangenheit der Fall, doch im Frühjahr 2021 änderte Apple dieses Verhalten maßgeblich.

Fehlercode geändert
Die Apple-Server antworten nun bei hoher Last nicht mehr mit "CKErrorRequestRateLimited", sondern mit "503 – Service unavailable" (bzw. CKErrorServiceUnavailable). Beiden Fehlerantworten ist aber gemein, dass diese eine "Retry-After"-Angabe ("Versuch es ach einer gewissen Zeit erneut"-Angabe) enthalten. MacStammbaum verhielt sich bis zum Frühjahr 2021 so, dass nach zwei "503 – Service unavailable"-Antworten der Sync-Vorgang abgebrochen wurde und der Nutzer benachrichtigt wurde.

Eine Anpassung des Verhaltens, dass nun "CKErrorRequestRateLimited" und "CKErrorServiceUnavailable" gleich behandelt werden, wenn eine "Retry-After"-Angabe vorhanden ist, behob diesen Fehler für die allermeisten Kunden. Scheitert eine Anfrage, wird diese nach der geforderten Zeit erneut gestellt – unabhängig davon, ob CloudKit als Fehler "CKErrorServiceUnavailable" oder (den richtigen) "CKErrorRequestRateLimited" zurücklieferte. Es ist auch nicht ungewöhnlich, dass bei einer erneuten Anfrage CloudKit abermals einen Fehler mit "Retry-After"-Angabe zurückliefert – und hier muss erneut gewartet werden.

"Einbremsen" abhängig von Last
Dass viele Kunden von betroffenen Apps nur ab und an Fehlermeldungen erhalten, ist recht einfach zu erklären: Wie schnell iCloud eine App "einbremsen" will, hängt von der Last der iCloud-Infrastruktur ab. Im Normalfall ist es möglich, dass ein Nutzer zehntausende Einträge auf CloudKit hochlädt, ohne dass es zu einer Limitierung kommt. Herrscht aber gerade große Last auf der iCloud-Infrastruktur, liefert CloudKit schon nach dem Hochladen einiger hundert Einträge Fehlermeldungen zurück, es in Kürze noch einmal zu probieren.

Apple-Dokumentation und Kommunikation: Mangelhaft
Viele Entwickler fragten bei Apple wegen den vielen "503 - Service unavailable"-Fehlern an – und erhielten keine konkreten Antworten. Apple dokumentiert diese Änderung aus dem Frühjahr 2021 aktuell an keiner Stelle, welche den Programmcode von vielen Entwicklern negativ beeinflusst. Laut den Apple-Entwickler-Anleitungen ist für den Fehlercode "503 Service unavailable" keine "Retry-After"-Angabe vorgesehen – doch seit Frühjahr 2021 liefern die iCloud-Server diese zurück.


Auch ist völlig schleierhaft, warum Apple diese Änderung durchführte – obwohl seit der ersten Version des CloudKit-Frameworks eine entsprechende Fehlerart deklariert ist und somit keine Notwendigkeit besteht, eine derart generische Fehlermeldung für eine Anfrage-Begrenzung zu missbrauchen.

Kommentare

cfkane25.01.22 11:09
Danke für den Beitrag, mal eine interessante Abwechslung im Themenbereich.
Erscheint wirklich erstmal seltsam, daß Apple jetzt so eine generische Fehlermeldung verwendet.
Aber immerhin steht ja in der abgebildeten Doku zu CKErrorRequestRateLimited, daß bei "any CloudKit error" auf die Retry-After-Angabe geprüft werden soll. Da erscheint es auch schon wieder halbwegs konsistent
+5
milk
milk25.01.22 11:41
Vielen Dank für den Artikel, hat mich sehr gefreut, mal wirklich eigenen Content bei euch zu lesen.
+8
dan@mac
dan@mac25.01.22 11:44
CloudKit ist toll, gerade auch in Verbindung mit CoreData - wenn es funktioniert.
+2
heubergen25.01.22 13:30
Für mich ist die Änderung schlüssig zu erklären; Sicherheitsforscher/Fanatiker sehen es ungern wenn ein Dienst überhaupt irgendeine Information dazu abgibt was im Hintergrund passiert. Statt also zu sagen dass das Passwort abgelaufen ist, das Passwort falsch ist oder der Account gesperrt wurde, steht einfach immer Passwort falsch.

Hier könnte es ähnlich verlaufen und jemand bei Apple will nicht das wir/die Entwickler herausfinden ob der Dienst gerade am Anschlag ist oder ob der komplett weg ist. Lieber wird eine generische Fehlermeldung angegeben.
0
frankh25.01.22 15:42
heubergen
Lieber wird eine generische Fehlermeldung angegeben.

Hierarchy of Mistakes:
1. General Failure
2. Major Problem
3. Hidden Vice

SCNR
+2
Colonel Panic
Colonel Panic25.01.22 18:21
frankh
Hierarchy of Mistakes:
1. General Failure
2. Major Problem
3. Hidden Vice

4. Colonel Panic
frankh
SCNR

dito
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.