Einstieg in SwiftUI

Inhaltsverzeichnis

Vorbei sind die Zeiten, in denen man Views sowohl im Code als auch in Interface-Dateien getrennt voneinander erstellte und konfigurierte. View-Controller, die in der Regel den Großteil bisheriger App-Projekte ausmachen, sollen ebenfalls dank SwiftUI so gut wie ausgedient haben. Stattdessen kommen Views zum Einsatz, die Daten anhand ihres Status und ihrer Model-Informationen in geeigneter Form präsentieren.

SwiftUI bringt ein umfangreiches Set an System-Views mit, die sich in allen aktuellen Plattformen von Apple verwenden lassen. Dazu gehören unter anderem Labels, Buttons, Switches und Listen. Abhängig vom Betriebssystem, unter dem sie verwendet werden, passt sich ihr Erscheinungsbild automatisch an. Das Erstellen der Views läuft indes (von kleineren Details abgesehen) identisch ab. Ein Button wird also mit SwiftUI immer auf die gleiche Weise für macOS, iOS, iPadOS, watchOS und tvOS gebaut.

Mit SwiftUI erstellte Views basieren auf dem View-Protokoll. Das setzt zwingend die Implementierung einer sogenannten body-Property voraus. Diese enthält das Aussehen und die Funktionsweise einer View. Eine Ansicht, die ein simples "Hello world" ausgibt, lässt sich so mit folgendem Code erstellen:

struct HelloWorldView: View {
    var body: some View {
        Text("Hello world")
    }
}

Der Typ der body-Property entspricht some View. Damit bringt man zum Ausdruck, dass diese Property selbst eine View zurückliefert, ohne dass man den exakten Typ der View angibt. Bei Text handelt es sich um einen Typ aus dem SwiftUI-Framework, der zum Erstellen von Labels dient und beim Initialisieren einen String mit dem anzuzeigenden Text erwartet.

Wie eine solche View aussieht, lässt sich direkt in Xcode 11 überprüfen. Dafür kommt ein neues Feature namens Preview zum Einsatz, das den Editor-Bereich in zwei Abschnitte aufteilt. Auf der linken Seite ist der Code zu sehen, rechts eine Vorschau der View. Um die zu erstellen, ist einmalig die Resume-Schaltfläche am oberen rechten Rand des zweiten Editor-Abschnitts zu betätigen. Xcode kompiliert daraufhin das Projekt und zeigt im Anschluss die erstellte View an (s. Abb. 1).

Änderungen an der View werden nun unmittelbar in der Vorschauansicht übernommen. Einzige Ausnahme bilden komplexere Änderungen innerhalb der View wie das Hinzufügen von Properties. Das erfordert ein erneutes Kompilieren des Projekts, weshalb man die Preview dann mittels erneutem Klick auf die wieder erscheinende Resume-Schaltfläche händisch aktualisieren muss.

Sollte der Preview-Bereich nicht angezeigt werden, lässt er sich jederzeit über die in Xcode 11 neu eingeführten Editor Options einblenden. Dort muss die Einstellung "Canvas" aktiv sein, damit die Preview sichtbar ist. Wen sie stört, hat über diese Einstellung umgekehrt die Möglichkeit, die Preview auch vollständig auszublenden.

Views gruppieren

Im bisher gezeigten Beispiel wurde ein einfaches Label erstellt. In den meisten Fällen setzen sich Views aber aus mehreren verschiedenen Elementen zusammen, die man miteinander gruppiert. In SwiftUI setzen Entwickler eine solche Gruppierung mit Stacks um. Die gibt es in drei Ausführungen: als V-, H- und Z-Stack. Ein V-Stack ordnet Views vertikal an, ein H-Stack horizontal. Mit einem Z-Stack legt man Views hintereinander ab und stapelt sie so aufeinander (ideal beispielsweise, um einen Text über eine im Hintergrund befindliche Grafik zu legen).

Um einen der genannten Stacks in SwiftUI zu erzeugen, nutzt man die zugehörigen Typen: VStack, HStack oder ZStack. Sie erwarten beim Erstellen neuer Instanzen ein Closure als Parameter. Darin werden alle Views untergebracht, die Teil des jeweiligen Stacks sind. Hierbei ist auch eine Verschachtelung von Stacks möglich. Beispielsweise kann ein H-Stack einen V-Stack als View enthalten und umgekehrt.

Das folgende Codebeispiel demonstriert den Einsatz der genannten Stacks und stellt zugleich ein weiteres View-Element aus dem SwiftUI-Framework vor: Image. Wie der Name andeutet, lassen sich damit Bilder in Ansichten einbetten. Dazu können Entwickler sowohl auf Bilder innerhalb von Asset Catalogs als auch auf die Grafiken der SF-Symbols-Bibliothek zugreifen. Um letztere zu verwenden, kommt der Initializer init(systemName:) zum Einsatz, der die Bezeichnung des gewünschten SF-Symbols als Parameter entgegennimmt.

struct ContentView: View {
    var body: some View {
        VStack {
            Text("Hello world")
            HStack {
                Text("Text with image:")
                Image(systemName: "house.fill")
            }
            Image("Graz")
        }
    }
}

Das Ergebnis des Codebeispiels ist in der Preview in Abbildung 2 zu sehen. Der Aufbau ist wie folgt: Herzstück der View ist ein V-Stack, der über insgesamt drei Views verfügt, die untereinander angeordnet werden. An oberster Stelle befindet sich ein Text, am Ende wird ein Bild angezeigt. Dazwischen kommt ein H-Stack zum Einsatz, der einen Text und eine Grafik aus der SF-Symbols-Bibliothek nebeneinander darstellt.

Beim Erstellen von Views in SwiftUI spielen Stacks eine essenzielle Rolle. Durch sie gruppiert man mehrere Views miteinander und ordnet sie auf die gewünschte Art und Weise an.

View-Modifikationen

Alle eingesetzten Views haben ihre Konfigurtionen bei ihrer Initialisierung erhalten. Stacks wurden hierbei die zugehörigen Ansichten übergeben, während Text- und Image-Elemente die passenden Inhalte erhielten. Um Views in SwiftUI aber weiter anzupassen – beispielsweise zum Festlegen einerTextgröße oder -farbe –, gibt es die sogenannten Modifier. Das sind Methode, die bestimmte Anpassungen an einer View durchführen. Als Ergebnis liefert ein Modifier eine neue View zurück, die die gewünschten Modifikationen enthält.

Das SwiftUI-Framework enthält eine Vielzahl solcher Modifier. Welche es konkret für einen bestimmten Typ wie Text oder Image gibt, lässt sich anhand der Dokumentation ermitteln. Beispielhaft präsentiert der Artikel eine kleine Auswahl der verfügbaren Modifier. Betrachtet sei zunächst das Text-Element. Die folgende Liste gibt einen kleinen Überblick, welche Anpassungsmöglichkeiten unter anderem dank der verfügbaren Modifier zur Verfügung stehen:

• Ändern der Textfarbe: foregroundColor(_:)
• Ändern der Schriftstärke: fontWeight(_:)
• Ändern der Schriftformatierung (als Titel, Untertitel etc.): font(_:)
• fett: bold()
• kursiv: italic()
• unterstrichen: underline()

Um eine der Anpassungen an einer Text-Instanz vorzunehmen, ruft man den gewünschten Modifier schlicht darauf auf. Um mehrere Änderungen auf einmal durchzuführen, reiht man alle zugehörigen Modifier aneinander. Möchte man so beispielsweise einen Text fett formatieren und kursiv setzen, führt man den folgenden Befehl aus:

Text("Hello world").bold().italic()

Bei der Arbeit mit SwiftUI setzt man jeden Modifier typischerweise in eine neue Zeile und rückt ihn ein. Das sorgt für eine bessere Übersichtlichkeit (dazu gleich mehr). Ein vollständiges Beispiel des Einsatzes mehrerer Modifier finden Entwickler im folgenden Codestück. Dort gibt es neben den genannten Methoden zur Anpassung von Text-Instanzen Modifier für die Konfiguration von Bildern. So kann man deren Größe durch den Aufruf von resizable() anpassen und den gewünschten Frame mit frame(width:height:alignment:) setzen. Um die Ecken von Grafiken abzurunden, nutzt man die Methode cornerRadius(_:).

struct ContentView: View {
    var body: some View {
        VStack {
            Text("Hello world")
                .foregroundColor(.blue)
                .font(.largeTitle)
                .fontWeight(.heavy)
                .underline()
            HStack {
                Text("Text with image:")
                    .italic()
                Image(systemName: "house.fill")
                    .resizable()
                    .foregroundColor(.green)
                    .frame(width: 50, height: 50)
            }
            Image("Graz")
                .cornerRadius(10.0)
        }
    }
}

Anpassung über Library und Preview

Eine View muss man jedoch nicht ausschließlich im Code erstellen. Mit der Library von Xcode haben Entwickler Zugriff auf die verfügbaren Views und Modifier und können sie direkt daraus einer SwiftUI-View hinzufügen. Dazu ziehen sie einfach wie gewohnt das gewünschte Element direkt an die passende Stelle im Code. Views und Modifier werden hierbei getrennt voneinander in der Library aufgeführt und besitzen jeweils einen eigenen Reiter (s. Abb. 3).

Die Library ist übrigens nicht nur praktisch, um Elemente aus ihr via Drag & Drop einer View hinzuzufügen. Sie bietet auch einen Überblick über die verfügbaren Elemente des SwiftUI-Frameworks. Insbesondere die Liste der Modifier ist für den Einstieg hilfreich, nicht zuletzt da die Library über eine Suchfunktion verfügt. Zum Beispiel lässt sich schnell ermitteln, welche Möglichkeiten zur Anpassung von Schriften in SwiftUI zur Verfügung stehen (s. Abb. 4).

Neben der Library haben Entwickler aber auch die Möglichkeit, diverse Anpassungen an Views über die in Xcode integrierte Preview vorzunehmen. Dazu wählen sie das gewünschte Element aus (z.B. einen Text oder ein Bild) und wechseln in den Attributes Inspector. Dort findet man – ähnlich wie man das aus der Arbeit mit Storyboards kennt – diverse Konfigurationsmöglichkeiten (welche genau das sind, hängt von der gewählten View ab). Bei Text-Instanzen beispielsweise können Entwickler unter anderem die Farbe und Formatierung festlegen (s. Abb. 5). Auch ist es möglich, Views und Modifier aus der Library statt im Code an der gewünschten Stelle in der Preview einzufügen.

Wer mit der Preview gearbeitet und Anpassungen vorgenommen hat, dem fällt womöglich auf, dass sich jede Änderung in der Vorschau unmittelbar auf den Code auswirkt. Ändert man beispielsweise die Farbe eines Texts über den Attributes Inspector, wird im Code der View der passende Modifier automatisch ergänzt. Diese Systematik hängt damit zusammen, dass es in SwiftUI keine Trennung zwischen Code und Interface-Dateien gibt, so wie das bei der Arbeit mit Storyboards der Fall ist. Tatsächlich zählt bei einer SwiftUI-View nur der Code. Die von Xcode generierte Preview ist ein Spiegel des Codes, und deshalb führen Anpassungen an ihr auch immer zu einer zugehörigen Anpassung des Quelltexts.

Views und ihr Status

Unter SwiftUI fällt die Rolle des View-Controllers weg. Stattdessen werden Daten, die eine View darstellen oder verarbeiten soll, direkt an diese weitergegeben. Solche Daten, die für die Darstellung einer View und für ihre Funktionsweise verantwortlich sind, bezeichnet man als "source of truth". Ihre einfachste Form stellt eine Property dar. Sie spiegelt einen Status einer View wider, der bei Initialisierung der View festgelegt wird. In Properties gespeicherte Daten werden somit also von außen gesetzt und sind anschließend unveränderbar.

Ein einfaches Beispiel für den Einsatz von Daten auf Basis einer Property zeigt das folgende Codebeispiel. Die "source of truth" stellt hier die title-Property dar, für die ein passender Wert beim Initialisieren einer ContentView-Instanz zu übergeben ist. Die View zeigt ein simples Label an, dessen Inhalt sich auf die title-Property bezieht.

struct ContentView: View {
    
    var title: String
    
    var body: some View {
        Text(title)
    }
    
}

let myContentView = ContentView(title: "Hello world")

Wie aber geht man mit Daten um, die veränderbar sind? Als Beispiel soll eine View mit einem Text und einem Button umgesetzt werden. Der Text wird standardmäßig als Headline formatiert, lässt sich alternativ aber auch als Large Title darstellen. Diese Einstellung soll in einer Property namens useLargeTitle gespeichert und bei Betätigen des Buttons invertiert werden.

Um das zu ermöglichen, ist eine entsprechende Property (in diesem Fall useLargeTitle) mit dem Property Wrapper @State zu deklarieren. Er bringt zum Ausdruck, dass die Property eine veränderbare Statusinformation enthält, die wichtig für die Darstellung der View ist. Das hat zur Folge, dass bei einer Änderung einer solchen @State-Property die View neu gezeichnet wird. Bei Betätigung des Buttons brauchen Entwickler also nur die useLargeTitle-Property zu ändern, und die View wird im Anschluss passend aktualisiert; ein expliziter Reload ist von Entwicklerseite nicht nötig.

Zwei Dinge sind beim Einsatz von @State zu beachten: So deklarierte Properties müssen immer über einen Standardwert verfügen und werden typischerweise als private gekennzeichnet. Letzteres hängt damit zusammen, dass @State-Properties nur für Daten genutzt werden sollen, die explizit mit der View zusammenhängen. Sie werden also beispielsweise nicht dazu verwendet, um Informationen aus dem Model zu laden und zu speichern.

Wie der Einsatz von @State beispielhaft aussehen kann, zeigt das nächste Codebeispiel. Die useLargeTitle-Property ist passend deklariert und besitzt den Standardwert false. In der Implementierung der body-Property der View wird dann innerhalb eines V-Stacks zunächst der Wert der useLargeTitle-Property überprüft und abhängig vom Ergebnis eine von zwei Text-Varianten erstellt. Im Anschluss folgt noch die Erstellung der Schaltfläche mit dem SwiftUI-Typ Button. Der erwartet zwei Parameter, bei denen es sich um Closures handelt. Das erste definiert die Aktionen, die bei Betätigung des Buttons ausgeführt werden sollen (in dem Fall eine Invertierung der useLargeTitle-Property). Das zweite Closure definiert das Aussehen des Buttons. Im Beispiel wird dazu ein simpler Text mit dem Inhalt "Change presentation" genutzt:

struct ContentView: View {
    
    @State private var useLargeTitle = false
    
    var body: some View {
        VStack {
            if useLargeTitle {
                Text("Hello world")
                    .font(.largeTitle)
            } else {
                Text("Hello world")
                    .font(.headline)
            }
            Button(action: {
                self.useLargeTitle.toggle()
            }) {
                Text("Change presentation")
            }
        }
    }
    
}

Neben diesen beiden gezeigten Varianten gibt es noch eine dritte Möglichkeit, einen veränderbaren Status einer View abzubilden. Sie funktioniert wie der Einsatz von @State, allerdings mit dem Unterschied, dass die View diese Statusinformation nicht selbst hält. Sie wird stattdessen von einer anderen View gespeichert.

Zum besseren Verständnis soll das Thema anhand des nächsten Beispiels erläutert werden. Basis ist die ContentView, die über eine @State-Property namens isActive verfügt. Anhand dieser Information wird entweder der Text "aktiv" oder "inaktiv" innerhalb der View ausgegeben.

struct ContentView: View {
    
    @State var isActive = false
    
    var body: some View {
        HStack {
            Text(isActive ? "Aktiv" : "Inaktiv")
            StarButton(isActive: $isActive)
        }
    }
    
}

struct StarButton: View {
    
    @Binding var isActive: Bool
    
    var body: some View {
        Button(action: {
            self.isActive.toggle()
        }) {
            Image(systemName: isActive ? "star.fill" : "star")
        }
    }
    
}

Daneben besitzt ContentView ein weiteres Element, das neben dem Text angezeigt wird. Es handelt sich um eine zweite eigens kreierte View namens StarButton. Sie stellt eine simple Schaltfläche dar, die entweder einen gefüllten oder ungefüllten Stern anzeigt. Gespeichert ist diese Informationebenfalls in einer Property namens isActive. Bei Betätigung des Buttons wird der Wert jener Property invertiert.

Gegeben sind somit zwei Views, die beide als Status jeweils eine eigene isActive-Property besitzen. In diesem Szenario ist der Wert der isActive-Property des StarButton aber einzig und allein von der ContentView abhängig. Sie bestimmt über ihre eigene isActive-Property, ob die Schaltfläche aktiv ist oder nicht. StarButton muss also nicht selbst diese Information speichern, sondern stattdessen auf die aus der ContentView zurückgreifen, sie auslesen und bei Betätigung verändern.

Um das umzusetzen, nutzen Entwickler den Property-Wrapper @Binding. Damit deklarieren sie Properties, die einen Status einer View widerspiegeln, die entsprechende Information aber von einer anderen Stelle erhalten (in diesem Fall von der ContentView). Im Gegensatz zu @State-Properties besitzen solche auf Basis von @Binding keinen Standardwert und werden auch nicht als private gekennzeichnet (schließlich ist eine entsprechende Information für diese Properties zwingend von außen an die View übergeben).

@Binding-Properties lassen sich nur anderen Status-Properties zuweisen (also beispielsweise solche, die mit @State deklariert sind). Bei einer solchen Zuweisung ist zusätzlich der jeweiligen Status-Property ein $-Zeichen voranzustellen.

Zum besseren Verständnis sollen die drei genannten Vorgehensweisen zum Abbilden eines View-Status noch einmal zusammenfasst werden:

• Property: nicht veränderbare Daten einer View. Sie werden einmalig bei der Initialisierung übergeben
• @State-Property: veränderbare Daten einer View. Sie werden typischerweise als private deklariert und benötigen zwingend einen Standardwert.
• @Binding-Property: veränderbare Daten einer View. Die entsprechende Information ist in einer anderen View gespeichert.

Gemein ist allen drei, dass sie sich auf Daten beziehen, die eng mit der jeweiligen View verzahnt und unabhängig vom Model einer App sind.

@Binding in SwiftUI

Properties auf Basis von @Binding finden sich übrigens an vielen Stellen im SwiftUI-Framework wieder. Betrachtet sei hier als Beispiel die View Toggle, die zum Abbilden von Schaltern dient. Jede Toggle-Instanz benötigt eine @Binding-Property vom Typ Bool als Parameter. Diese nutzt Toggle dazu, einerseits die initiale Darstellung festzulegen (an oder aus) sowie bei einer Änderung die übergebene Datenbasis zu verändern.

Da eine View wie Toggle an den unterschiedlichsten Stellen zum Einsatz kommt und hierbei immer eine andere Datenbasis nutzt, ist die Verwendung einer @Binding-Property ideal. So weiß Toggle lediglich, wo sich die Daten befinden, die für das Erscheinungsbild des Schalters verantwortlich sind, und kann diese bei Betätigen des Schalters direkt anpassen. Der praktische Einsatz von Toggle ist in einem kleinen Beispiel demonstriert:

struct ContentView: View {
    
    @State var isActive = false
    
    var body: some View {
        Toggle(isOn: $isActive) {
            Text("Schalter")
        }
    }
    
}

Umgang mit externen Daten

Mit Properties, @State und @Binding haben Entwickler drei Möglichkeiten kennengelernt, um Informationen abzubilden, die direkter Teil einer View sind. Doch was ist mit jenen Daten, die nicht explizit zu einer View gehören und stattdessen aus einer externen Quelle stammen, beispielsweise dem Model einer App? Für derartige Daten kommt der Property Wrapper @ObservedObject zum Einsatz. Er wird genauso eingesetzt wie der Property Wrapper @State, nur dass die zugehörigen Daten hier aus einer externen Quelle stammen und nicht Bestandteil einer View sind.

Bevor man allerdings externe Daten in SwiftUI verwenden kann, sind die noch entsprechend vorzubereiten. Dazu muss man die Daten in Form einer Klasse abbilden, die konform zum ObservableObject-Protokoll ist. Zusätzlich versieht man jede Property innerhalb der Klasse, bei deren Änderung eine Aktualisierung einer View erfolgen soll, mit dem Property Wrapper @Published. Damit besitzt das System alle Informationen, die es benötigt, um die externen Daten als Basis für SwiftUI zu nutzen. Ändern sich mit @Published deklarierte Properties, werden Views, die auf diesen Daten basieren, entsprechend automatisch aktualisiert.

Ein Beispiel für auf die beschriebene Art und Weise angepasste externe Daten stellt die Klasse Settings im nächsten Codestück dar. Sie ist konform zum ObservableObject-Protokoll und besitzt die Property username, die zur Speicherung eines Nutzernamens innerhalb einer App dient. Damit bei einer Änderung des Nutzernamens Views automatisch aktualisiert werden, ist die Property passend mit @Published deklariert.

class Settings: ObservableObject {
    @Published var username = ""
}

Um diese Daten nun als Teil einer SwiftUI-View zu nutzen, erstellt man eine Property des entsprechenden Typs (in diesem Fall Settings) und deklariert sie mit dem Property Wrapper @ObservedObject. Im nächsten Beispiel ist das Prinzip zu erkennen. Die dort deklarierte UsernameView nimmt die Einstellungen über eine settings-Property entgegen und nutzt die darin enthaltene Information, um den Nutzernamen in einem Label auszugeben. Darüber hinaus verfügt die View über ein Textfeld, über das sich der Nutzername ändern lässt. Dazu wird der TextField-Instanz der Verweis auf den Nutzernamen als Binding übergeben; das wäre nicht möglich, wenn die settings-Property nicht mit dem Property Wrapper @ObservedObject deklariert wäre.

struct UsernameView: View {
    
    @ObservedObject var settings: Settings
    
    var body: some View {
        VStack {
            Text("Current username: \(settings.username)")
            TextField("Username", text: $settings.username)
        }
    }
    
}

Eine Alternative zu @ObservedObject stellt der Property Wrapper @EnvironmentObject dar. Er hat dieselbe Aufgabe wie @ObservedObject und erlaubt es, externe Daten in Views zugänglich zu machen. Der Unterschied besteht darin, dass sich diese Daten beim Einsatz von @EnvironmentObject an einer beliebigen Stelle innerhalb eines Projekts in eine View injizieren lassen. Daten sind so nicht über mehrere View-Ebenen weiterzureichen, bis sie letztlich jene View erreicht haben, für die sie bestimmt sind.

Um Daten einer View auf Basis des Property Wrapper @EnvironmentObject zu übergeben, kommt die Methode environmentObject(_:) zum Einsatz, die sich auf allen Views aufrufen lässt. Als Parameter übergibt man eine passende Dateninstanz. Wäre so beispielsweise die settings-Property der Structure UsernameView dem vorangegangenen Beispiel mit @EnvironmentObject deklariert, müsste man eine Instanz der View wie folgt erzeugen:

let mySettings = Settings()
UsernameView().environmentObject(mySettings)

Bei der Arbeit mit @EnvironmentObject müssen Entwickler aber aufpassen. Der Compiler informiert sie in diesem Fall nicht, falls sie den Aufruf der environmentObject(_:)-Methode vergessen und so einer View möglicherweise nicht die Daten übergeben, die sie zwingend benötigt. Sollte das tatsächlich der Fall sein, führt das beim Erstellen einer entsprechenden View zu einem Absturz der Anwendung.

Fazit

SwiftUI hat das Potenzial, das Erstellen von Benutzeroberflächen für die verschiedenen Plattformen von Apple maßgeblich zu verändern. SwiftUI erhebt den Anspruch, deutlich komfortabler zu sein als die bisherige UI-Erstellung auf Basis von Views und View-Controllern. Da SwiftUI für alle Plattformen von Apple zur Verfügung steht, reicht es, wenn Entwickler einmal gelernt und verstanden haben, wie SwiftUI funktioniert. Das Wissen können sie dann für alle Apple-Plattformen nutzen.

Hierbei sei eines abschließend aber noch klargestellt: SwiftUI ersetzt nicht das Erstellen individueller Views für die einzelnen Plattformen von Apple. Es liegt in der Natur der Sache, dass sich für den Fernseher optimierte Ansichten nicht einfach eins zu eins auf das kleine Display einer Apple Watch übertragen lassen. Aber dank SwiftUI kann man für alle Plattformen dasselbe Toolset für die Gestaltung von Nutzeroberflächen einsetzen, und letztlich ist das eine der größten Stärken von SwiftUI.

Bleibt die Frage, ob Entwickler bereits jetzt auf SwiftUI umsatteln sollten. Die Antwort darauf lautet wohl: jein. Es scheint außer Frage zu stehen, dass SwiftUI langfristig das Framework der Wahl zum Erstellen von Nutzeroberflächen für Apple-Plattformen sein wird. Zum jetzigen Zeitpunkt allerdings fehlt es an einigen Stellen noch an Dokumentation, was die Arbeit mit dem Framework erschwert. Darüber hinaus steht SwiftUI nur für die neuesten Betriebssystemversionen (iOS 13, macOS Catalina 10.15 usw.) zur Verfügung.

Wer eine App nur für die aktuellsten Plattformversionen von Apple entwickelt und sich an ein wenig Herumprobieren aufgrund fehlender Dokumentation nicht stört, kann SwiftUI sicherlich schon im Produktiveinsatz eine Chance geben. Alle anderen Entwickler sollten sich ebenfalls mit dem Framework vertraut machen und wenigstens dessen Funktionsweise verstehen, doch der praktische Einsatz kann da noch ein wenig auf sich warten lassen.

Thomas Sillmann
ist Autor, Apple Developer und Trainer. Mit seiner Begeisterung für das Schreiben hat er bereits mehrere Fachbücher, Fachartikel sowie Online-Kurse veröffentlicht. Thomas lebt und arbeitet in Aschaffenburg. (ane)