List ist eines der wichtigsten Steuerelemente in SwiftUI, denn kaum eine Anwendung kommt ohne sie aus. Auf der iOS-Plattform ist es oft unumgänglich, Daten in Listen anzuzeigen, denn der kleine Bildschirm ermöglich oft keine andere sinnvolle Darstellung. Aus der List kann dann oft zu einer Detailansicht der ausgewählten Daten navigiert werden.
Der Blur-Modifier von SwiftUI wird in vielen Fällen ausreichen, um ein Bild, oder eine kompletten View, verschwommen anzuzeigen. Mehr Kontrolle erhält man jedoch, wenn stattdessen ein UIVisualEffectView mit einem UIBlurEffect zum Einsatz kommen. Wir die Namen es vermuten lassen, haben es diese beiden Klassen noch nicht in das SwiftUI-Framework geschafft. Es sind UIKit-Klassen. Zwar können auch diese problemlos verwendet werden, es ist nur etwas mehr Aufwand nötig.
Über den Sinn und Unsinn von Erweiterungsmethoden, den sogenannten Extensions, habe ich mit meinen Kollegen oft diskutieren müssen. Viele der Windows-Entwickler meiden sie. In der Apple-Welt ist man zum Glück etwas aufgeschlossener. Ich persönlich halte Extensions für eine tolle Sache. Statt von Klassen erben zu müssen können einer bestehenden Klasse zusätzliche Funktionen hinzugefügt werden. Wenn man diese Vorgehensweise verfolgt, entwickelte sich automatisch eine Bibliothek von Funktionen, die viele Aufgaben des Programmieralltags abdeckt und die jederzeit wiederverwendet werden kann.
Im Unterschied zu enum-Typen in anderen Programmiersprachen sind die Enumerationen in Swift flexibler einsetzbar, denn sie sind mehr, als nur Aufzählungen von Werten. In Swift kann eine Enumeration Methoden enthalten und ermöglicht somit zusätzliche Möglichkeiten bei der Entwicklung. Folgt ein enum dem CaseIterable-Protokoll können alle Werte sogar leicht mit einer Schleife durchlaufen werden.
Mit der Veröffentlichung von macOS Big Sur hat Apple viele der eigenen Anwendungen auf ein neues Design umgestellt. Programme verfügen jetzt auf der linken Seite des Fensters über eine schmale Seitenleiste, der Arbeitsbereich befindet sich rechts daneben. Oft wird dieses Layout für eine Master-Detail-Navigation verwendet. Nach Auswahl eines Elements aus der Seitenleiste ändert sich die Ansicht im Arbeitsbereich. Nicht selten wird dabei die komplette View getauscht. Die Anwendungen Musik, Notizen oder Erinnerungen sind nur drei Beispiele, die diesem Design folgen.
Obwohl es schon seit einigen Jahren existiert, ist SwiftUI immer noch ein junges Framework und mache Dinge funktionieren nicht, wie erwartet. Entweder, weil das Framework sie falsch umsetzt, oder weil Entwickler Fehler machen. Man kann sich nie sicher sein, was der Fall ist. Seltsame Probleme entstehen dabei nicht selten bei Programmcode, der auf den ersten Blick einfach erscheint.
Vor einigen Wochen begann ich mit der Entwicklung einer iOS-App, mit der ich Features von SwiftUI ausprobieren wollten. In der ersten Version der App hatte ich für jede View einen NavigationLink mit einer Beschreibung zum Thema direkt im Code des List-Steuerelements hinterlegt. Der Aufbau der Liste war somit statisch, es war aber auch nichts anders erforderlich. Immer, wenn ich ein Beispiel zu einem Thema vollendet hatte, fügte ich der List einen weiteren NavigationLink hinzu. In den ersten Tagen hat das gut funktioniert, doch dann stieß ich auf eine grundlegende Einschränkung von SwiftUI.
Ein ansprechendes Design für eine App zu entwicklen, ist keine einfache Aufgabe. Glücklicherweise bietet das SwiftUI-Framework ausreichend Möglichkeiten, die eigenen Ideen umzusetzen. Steuerelemente beispielsweise, können auf verschiedenste Art angepasst werden. Farben, Schriftart, Größe und Abstände sind nur einige der Eigenschaften, die manipuliert werden können.