Apples Cloud-Dienst soll Daten unauffällig im Hintergrund synchronisieren, sodass Nutzer gar nicht wahrnehmen, dass er arbeitet: Wechselt man das Gerät, sind die Daten schon da. So sehr sind die Entwickler in Cupertino von der Leistungsfähigkeit der iCloud überzeugt, dass Fortschrittsindikatoren anfangs gar nicht vorgesehen waren. Inzwischen erscheinen blasse Wolkenumrisse neben Dateien, die zwar in einem Ordner vorgesehen, aber lokal nicht vorhanden sind. Weiterhin unsichtbar bleibt der Sync-Prozess meist, wenn eine App CloudKit verwendet: Dieser Dienst synchronisiert Datenbankinhalte zwischen iCloud-Servern und Apps auf verschiedenen iPhones, iPads und Macs. Hierbei obliegt es der App, ob sie den Sync-Prozess anzeigen. Apple selbst verfährt da unterschiedlich: Die Fotos-App zeigt ein kleines Fortschrittsdiagramm, die Erinnerungen lediglich ein Drehrädchen.


Umso schwerer fällt die Erkennung, wie und warum ein bestimmter Datensatz beispielsweise auf dem Mac vorhanden ist, auf dem iPhone aber fehlt. Apple veröffentlichte jetzt ein Dokument, die über mögliche Ursachen aufklärt. Auch wenn es sich an Entwickler richtet, dürfte der Inhalt Nutzern helfen, mit App-spezifischen Sync-Problemen umzugehen.

Gründe für eine serverseitige Bremse
In Technote 3162 mit dem Titel "Understanding iCloud Throttles" beschreibt Apple zwei Szenarien, die dazu führen können, dass CloudKit zeitweilig nicht mehr synchronisiert. Das erste: Eine App führt zu viele Anfragen in kurzer Zeit aus. Das zweite: CloudKit wird mit unangemessenen Anfragemustern kontaktiert, weil sie beispielsweise von mehreren Geräten gleichzeitig mit mehreren Anfragen bombardiert wird.Apple gibt keine numerischen Obergrenzen an, die zum aus Anwendersicht ungewollten Einbremsen der Anfragen (“Throttling”) führen. Das Dokument beschreibt stattdessen die resultierende Fehlermeldung, die App-Entwickler abfangen sollten. CloudKit nutzt den HTTP-Statuscode 503 (Service unavailable), eingebettet in zusätzliche Informationen. Mit dabei ist ein Parameter ("Retry after") in Sekunden: Für diesen Zeitraum sitzt die App auf der CloudKit-Strafbank. Fragt sie vor Ablauf erneut den Sync-Dienst an, gibt es keine gewünschte Antwort; eher verlängert sich die Auszeit.

Warum überhaupt eine Bremse?
Apple bietet mit iCloud und CloudKit eigenen Programmen und auch Drittherstellern Zugriff auf gigantische Datenbankkapazitäten – doch auch diese sind nicht unendlich. Grundsätzlich muss sich Apple durch ein zwangsweises Einbremsen vor Anfragen gegen zwei Szenarien absichern. Das erste ist, dass eine App durch einen Programmierfehler kontinuierlich Anfragen stellt – und handelt es sich um eine vielgenutzte App, kann dies die Erreichbarkeit von iCloud und CloudKit einschränken. Apple erkennt derartige Muster und weist die App an, Anfragen später zu stellen. Das zweite Szenario betrifft die allgemeine Last: An machen Tagen, beispielsweise nach der Auslieferung neuer iPhones oder über die Weihnachtsfeiertage, ist die Last auf Apples Servern besonders hoch, da viele Geräte neu eingerichtet und somit viele Daten heruntergeladen werden. Damit iCloud nicht unter derartiger Last zusammenbricht, drosselt Apple die Frequenz von Anfragen.

Was nützt das Wissen dem Nutzer?
Als Anwender kann man natürlich schlecht Einfluss nehmen auf CloudKit-Anfragen einer App. Vielmehr könnten ahnungslose Nutzer vermuten, iCloud sei aktuell nicht erreichbar, erklärt Howard Oakley – oder schlussfolgern, die App synchronisiere dauerhaft nicht mehr über die iCloud. Die wahrscheinlich schlechteste Reaktion in diesem Fall ist gleichzeitig die am häufigsten vorgeschlagene bei Problemen mit Apples Sync-Dienst: Ab- und wieder Anmelden des iCloud-Accounts auf dem betroffenen Gerät. In diesem Fall erneuere sich höchstwahrscheinlich die CloudKit-Anfrage, was die Sperre wiederum verlängere. Stattdessen helfe nur, Ruhe zu bewahren. Entwicklern, die einer hartnäckigen CloudKit-Bremse auf die Spur kommen will, rät Oakley, die Logs des brctl-Prozesses zu durchforsten. Dafür empfiehlt er seine kostenlosen Tools Cirrus und Mints.