Einführung in CloudKit (Teil 1)

Anwendungen, die mit mehreren Clients auf verschiedenen Plattformen dem Nutzer jederzeit die gleichen Daten anbieten möchten, benötigen für den Austausch dieser eine zentrale Stelle. Diese zentrale Stelle ist oftmals ein klassischer Webserver (=Dienst), welcher mittels serverseitigem Code die Verarbeitung der Daten übernimmt.

Soll ein Nutzer nur auf die eigenen Daten zugreifen können, wird ein Nutzerkonto inkl. Authentifizierung benötigt. Des Weiteren wäre es ideal, wenn der Dienst auch entsprechend skaliert sobald mehr Nutzer die Anwendung in Anspruch nehmen um weiterhin niedrige Zugriffszeiten zu gewährleisten. Nebenbei verlangen immer mehr Anwendungsfälle auch das Bereitstellen bestimmter Daten an andere Nutzer des gleichen Dienstes oder an externe, anonyme Nutzer zur gemeinsamen Zusammenarbeit. Um über Änderungen an freigegeben Daten durch andere Nutzer informiert zu werden nutzen viele Dienste mittlerweile Notifications (=Meldungen), welche der geneigte Nutzer als kleine Meldungen auf seinem mobilen Gerät oder auf dem Desktop erhält.

Apple hat 2014 mit iCloud Drive die eigene Konkurrenz zu etablierten Anbietern wie Dropbox, Google Drive etc. vorgestellt. Die feste Integration in iOS und Mac OS erlaubt den unproblematischen Austausch von Daten zwischen Desktop und mobilen Geräten sowie die Bereitstellung dieser für andere iCloud-Nutzer oder externe Nutzer. Da bereits jeder Nutzer von iCloud ein iCloud-Konto besitzt erspart Apple bei Markteinführung ca. 400 Millionen Anwendern eine Anmeldung für den neuen Dienst.

iCloud Drive wurde von Apple mit dem auf der WWDC 2014 vorgestellten CloudKit umgesetzt. Apple hat ein großes Eigeninteresse, CloudKit soweit zu verbessern und mit neuen Funktionen auszustatten, wie es für das eigene Produkt iCloud Drive notwendig erscheint. Somit profitieren auch Anwendungen anderer Entwickler von CloudKit.
Mit CloudKit hat Apple für iOS 8 und Mac OS X einen kostengünstigen und einfachen Cloudservice mittels iCloud geschaffen.
Bei CloudKit handelt es sich um einen Service, nicht um einen konkrete Implementierung, welcher Daten zwischen der iCloud (und den dort befindlichen Datenbanken) und Clients austauscht.

CloudKit nimmt Entwicklern dabei das (meist kostenintensive) Entwickeln von serverseitiger Logik ab und ermöglicht die Konzentration auf reine clientseitige Anwendungsentwicklung.
Apple bietet dabei einige grundsätzliche Services wie Datenbanken, Authentifizierung, Medienspeicher, Suche und Notifications.

Komponenten von CloudKit

• Das Dashboard, um Daten einzusehen: https://icloud.developer.apple.com/dashboard
• Ein Reihe von API zum Austausch von Daten zwischen Client und iCloud

Limits und Kosten

Apple stellt Entwicklern kostenfrei ausreichende Limits zur Verfügung:

• 1 PB Mediendaten
• 10TB Datenbank
• 5TB/Tag Medientransfer
• 50GB/Tag Datenbankoperationen

Wer mehr Speicher und Transfervolumen benötigt, muss direkt mit Apple in Kontakt treten.

Sicherheit

Da für die Authentifizierung eines jeden Benutzers die bei der Einrichtung des Geräts eingetragenen Zugangsdaten zu iCloud auch für CloudKit verwendet werden, ist die Sicherheit der Daten insofern soweit gegeben, wie man als Nutzer Apple auch die anderen Daten in der iCloud anvertraut (Fotos, Notizen etc.).
Entwickler haben keinen Zugriff auf die in der iCloud befindlichen Daten eines Nutzers, solange dieser sich nicht gegen die iCloud authentifiziert. Anschließend hat ein Client nur Zugriff auf dort befindliche private eigene oder öffentliche Datenbanken anderer Nutzer. Es ist nicht möglich, private Daten anderer Nutzer aus der iCloud mittels CloudKit auszulesen oder zu manipulieren. Es gibt Möglichkeiten Datenbanken öffentlich bereitzustellen, welche dann anonym von anderen Clients editiert und gelesen werden können.

Aufbau

Der Datenaustausch zwischen Client und iCloud erfolgt über unstrukturierte Datenformate. Jede Clientanwendung erhält standardmäßig einen mit ihrer Bundle-ID benannten Container, welcher nur der eigentlichen Anwendung zur Verfügung steht. Weitere Container sind möglich, müssen aber eindeutig benannt sein (ähnlich wie App IDs).

Vorteile und Nachteile von CloudKit

Vorteile

• CloudKit besitzt ein aktuell unschlagbares Preis/Leistungsmodell im Vergleich zu anderen Anbietern wie Parse, Deployd etc.
• die Einrichtung erfolgt mit wenigen Klicks in Xcode (“ready-to-go”)
• fertiges Nutzermanagement mit sehr guten Datenschutzeinstellungen sowie der Möglichkeit, innerhalb dieses Ökosystems mit anderen Nutzern zu interagieren

Nachteile

• feste Bindung an die Apple Infratstruktur
• bisher keine Informationen über mgl. Exportmöglichkeiten
• kein eigener serverseitiger Code – d.h. was (aktuell) nicht durch CloudKit abgedeckt wird, ist nicht damit realisierbar

Jedoch ist davon auszugehen, das Apple in naher Zukunft auch CloudKit um die Möglichkeit zum Ausführen von eigenem serverseitigem Code erweitert und ggfs. auch das API anderen Plattformen gegenüber öffnet. Gegenwärtig ist es eine Investition in die eigenen (iOS) Plattform.

App ID anlegen und CloudKit Container erstellen

Bevor CloudKit in eine App eingebunden werden kann, muss die entsprechenden App ID im Developer Center dafür freigeschaltet werden.

Anschließend muss die App ID über App IDs > *Name der App ID* > Edit die iCloud Einstellungen der App ID konfiguriert werden. Standardmäßig ist kein iCloud Container zu einer App ID vorhanden und muss manuell erzeugt werden.

Als Identifier für den Container, welcher immer mit iCloud beginnen sollte, sollte der Identifier der App ID verwendet werden (im Beispiel “com.ucdplus.cloudkittest”)

Nach Abschluss der Erstellung muss der erstellte iCloud Container noch in den Einstellung von iCloud der App ID ausgewählt und aktiviert werden.

Alternativ zur manuellen Erstellen des CloudKit Containers über das Apple Developerportal ist auch die automatische Erstellung über Xcode möglich. Dazu muss eine gültige, aber eindeutige App ID (Empfehlenswert ist hier bei immer die Reverse domain name notation) für das Projekt im Reiter “Generals” des “Targets” (hier CloudKit-Test) definiert sowie das korrekte Team ausgewählt werden:

Anschließend kann CloudKit in Xcode für das entsprechende Target aktiviert werden und erstellt den notwendigen Container.

iCloud und CloudKit in Xcode aktivieren

Für die Beispielanwendung wurde ein neues Projekt in Xcode erzeugt, jedoch lässt sich iCloud und CloudKit auch in jeder bestehenden Anwendung über die Capabilities des Targets aktivieren.

Xcode verlangt daraufhin ggfs. die Zugangsdaten zum Apple Developerportal. Daraufhin werden die entsprechenden Libraries unter Build Phases verlinkt und die Einbindung von CloudKit kann beginnen.

Wenn CloudKit in einem Projekt aktiviert wird erstellt Xcode automatisch einen Standardcontainer, falls keiner im Apple Developerportal existiert. Hierbei ist zu beachten, dass die Containerbezeichnung global eindeutig sein muss – dies kann daher idealerweise durch die Verwendung des Reverse domain name nonation für die App ID sichergestellt werden, welche dann durch das Präfix “iCloud” als Containerbezeichnung genutzt wird.

CloudKit Dashboard

Nach der Integration der notwendigen IDs und Libraries in das Xcodeprojekt kann das CloudKit Dashboard über die URL https://icloud.developer.apple.com/dashboard/  oder den Button in Xcode im Reiter Capabilities des Targets aufgerufen werden.

Das CloudKit Dashboard bietet über eine Übersicht zu bereits in iCloud gespeicherten Daten.

Im Bereich Schema können dazu vorhandene Record Types, Security Roles und Subscription Types aufgerufen werden. Im folgenden Beispiel wird nur mit Record Types gearbeitet.

Record Types sind Vorlagen eines bestimmtes Typs, welcher mit Attributen ausgestattet werden kann. Im Sinne von objektorientierter Programmierung stellen Record Types Klassen dar. Ein einzelner Record kann jeweils als Instanz dieser Klasse (des Record Types) betrachtet werden. Die Attribute können einfache Strings, Datum, Zahlen aber auch Referenzen zu anderen Records oder Dokumenten darstellen (Übersicht der verfügbaren Attribute).

Mittels Security Roles können Zugriffsbereiche für Rollen auf bestimmte Record Types definiert werden.

Subscription Types bieten einen Überblick zu innerhalb von Apps angelegten Subscriptions.

Unter Public und Private Data besteht die Möglichkeit in den in iCloud gespeicherten Daten zu suchen oder in den verfügbaren (öffentlichen oder privaten Datenbanken) neue Einträge einzufügen.

Im Bereich Admin kann der Zugriff auf das CloudKit Dashboard verwaltet als auch das Deployment von der Development in die Production Umgebung angestoßen werden.

Record Type erstellen

Ein Record Type kann entweder über das CloudKit Dashboard oder durch speichern eines Records mit einem bestimmten Identifier aus der App heraus erzeugt werden. Das Anlegen eines Records Types erfolgt oben über das “+”-Zeichen, wobei im Menü links Record Types ausgewählt sein muss.
Anschließend wird ein Bezeichnung (eindeutiger Identifier) vergeben, welcher als Klassename gesehen werden kann. Darunter werden anschließend Attribute angelegt und deren Typ definiert.

Für die Beispielanwendung wird ein Record Type “NotesItems“ mit den Attributen title (Typ: String) und desc (Typ: String) angelegt. Rechts unten muss der Record Type abschließend gespeichert werden.

Im nächsten Teil werden wir eine kleine Beispielanwendung zur Verwaltung von Notizen mit Anbindung an iCloud umsetzen.