Die Testflight-Beta ist leider bereits abgelaufen. Wenn du die App dennoch ausprobieren möchtest, melde dich einfach bei mir.

— Das Böard: Dark Mode & Light Mode

— Eine neue Cärd hinzufügen

— App-Einstellungen: Theme-Farbe

Wiesö, Weshalb, Warum?

Die Grundidee der App ist zugegeben nicht sehr originell, aber ich habe sie dennoch gewählt, da ich als SwiftUI-Neueinsteiger möglichst viele verschiedene Bereiche und Funktionen von Swift & SwiftUI kennenlernen wollte. Durch die verschiedenen Inhaltstypen hatte ich die Möglichkeit mich komplett innerhalb einer App auszutoben. Yäy!

Inspiration für die App habe ich aus meiner Arbeit am Konzept der to•gather-App aus dem Kurs „Interface Design: Basics“ gezogen.

Prözess, Pröbleme und Herausförderungen

Da ich in meinem sonstigen Entwicklerleben eher im Web unterwegs bin, habe ich mich bei SwiftUI oft geärgert, dass Layouts nicht so einfach umzusetzen sind und in ihrer Struktur oft sehr speziell aufgebaut werden müssen. Deshalb musste ich mir oftmals mittels Trial & ganz viel Error den Weg zur Lösung bahnen.

Ursprünglich konnten Karten in meinem Entwurf auch quer über mehreren Spalten liegen und mittels Dräg & Dröp verschoben werden. In der Theorie eine relativ simple Idee. Aber dann kam das SwiftUI LazyGrid…

— SwiftUI LazyGrid, nachdem Max seine Anforderungen mitteilte

Nachdem das LazyGrid und ich also keine Freunde geworden sind, ging die Suche nach einem geeigneten Package für die Cärd-Gridifizierung weiter. Zunächst dachte ich, ich hätte mit dem ExyteGrid von Exyte den perfekten Kandidaten für die Lösung meiner Probleme gefunden. Doch leider freute ich mich zu früh, denn mir versalzten viele kleine Quirks und Bugs im Code des Grids die Suppe. Ich stand dann vor der Entscheidung, ob ich mich in den Code des ExyteGrids einarbeite um es für mich anzupassen oder ich meine Feature-Wünsche etwas zurückfahre. Nachdem ich nach kurzer Auseinandersetzung mit dem Code unfreiwillig Mathe-Leistungskurs-Flashbacks bekam, entschloss ich mich für die letztere Option.

Nach ein bisschen Suche stieß ich dann irgendwann auf das WaterfallGrid von Paolo Leonardi, welches wunderbar funktioniert und die Cärds im Endeffekt nur in ihrer Breite begrenzt. Durch diese Begrenzung konnte ich die Anzahl der Spalten für die User*innen einstellbar machen. Momentan ist das Grid für 1 bis 3 Spalten optimiert. Im Idealfall sollte sich die Anzahl an verfügbaren Spalten je nach Breite des Geräts anpassen. Das ist die perfekte Überleitung zum nächsten Punkt:

Äusblick

Die größte Baustelle die auf dem Weg zu einer offiziellen Version 1.0 noch vor mir liegt ist die zuverlässige Verwaltung der Daten. Momentan benutzt die App die UserDefaults um die Böards & Cärds der Nutzer*innen zu speichern. Doch gerade bei Bildern stößt man an dieser Stelle schnell an ein Limit… Erkenntlich wird dies, wenn die App Änderungen plötzlich nicht mehr speichert und Cärds nach dem Neustarten der App im Nichts verschwinden. Ich habe mir bereits Gedanken gemacht, wie ich dieses Problem umgehen kann. Einerseits gäbe es da Apples CloudKit was leider bei genauerer Betrachtung aufgrund der ähnlich strikten Beschränkungen bei der Dateigröße nicht in Frage kommt. Andererseits wäre Realm (Vielen Dank an Felix für das klasse Tutorial!) auch eine Option. Wenn ich ehrlich bin, möchte ich aber, dass die Daten meiner Nutzer*innen auf deren eigenen Geräten liegen und nicht den Weg in eine externe Cloud gehen.

Vermutlich wäre die einfachste Option statt Bildern nur Verweise auf Bilder in der Galerie der Nutzer*innen zu speichern und diese dann beim Öffnen des Böards zu laden.

Abgesehen von der Aufgabe, das Speicherproblem zu lösen, gibt es noch einige Features die ich einbauen möchte: Zum Beispiel wäre eine Integration in den Share-Dialog von iOS toll, sodass man nicht immer die App öffnen muss um Cärds zu erstellen.

Fäzit

SwiftUI macht super viel Spaß! Auch wenn ich mir für das Semester viel vorgenommen hatte, kam ich relativ schnell voran. Leider wurde meine anfängliche Motivation dann etwas abgebremst, sobald es an die gestalterischen & entwicklerischen (Ist das ein Wört?) Details ging. Oftmals musste man längere Zeit nach Ressourcen suchen, die einem helfen ein bestimmtes Thema zu verstehen, da Apples eigene Dokumentation oft sehr spärlich ausfiel. Zum Glück konnte man sich mit Problemen auch jederzeit an Martin oder den Kurs wenden.

Abschließend würde ich sagen, dass SwiftUI auch unter Designern eine große Relevanz hat und zunehmend haben wird. Vor allem Interface-Prototypen, die noch nicht viel Funktionalität beinhalten, lassen sich sehr schnell zusammenbauen und simulieren eine echte App viel besser als Klick-Prototypen aus den gängigen Tools, wie z.B. Sketch, Figma oder Invision.

In Zukunft werde ich auf jeden Fall weiter mit SwiftUI arbeiten, da ich nicht nur Swift als Programmiersprache toll finde, sondern ich auch gespannt bin, wie sich das Featureset der Apple-Geräte und auch die Möglichkeiten in SwiftUI in der Zukunft weiterentwickeln.