Seit 2019 steht Apples (inzwischen nicht mehr ganz so) neues Framework SwiftUI zur Gestaltung grafischer Oberflächen uns Entwicklern zur Verfügung. 2019 war auch das Jahr, in dem ich bereits voll auf SwiftUI setzte und mich von UIKit und Storyboards verabschiedete (soweit technisch möglich; was mit SwiftUI nicht ging, wurde mit Representables geregelt).
Mein Vorgehen wurde bei manchen Entwickler-Kollegen bisweilen – höflich ausgedrückt – mit Verwunderung aufgenommen. Schließlich war SwiftUI ja ein Beta-Produkt. Oder eine reine Spielerei. Ernsthafte App-Entwicklung war damit ja nicht möglich.
Manche Stimmen halten auch heute noch an diesen Punkten fest. Und mir scheint, dass nicht SwiftUI das Problem ist.
Imperativ vs. deklarativ
SwiftUI ist nicht UIKit. Das ist auch gut so, wo sonst wäre eine potenzielle Daseinsberechtigung? UIKit setzt voll auf den imperativen Ansatz zur Gestaltung von Nutzeroberflächen und zur Reaktion auf Events wie die Betätigung eines Buttons. SwiftUI hingegen verfolgt einen deklarativen Ansatz und setzt auf eine Beschreibung des View-Aufbaus. Events und View-Aktualisierungen werden mittels Status geregelt; ändert sich der Status, aktualisiert sich die zugehörige View. So einfach, so effektiv.
Seit der Verfügbarkeit von SwiftUI habe ich an vielen Apps mitgewirkt (sowohl eigene als auch Kundenprojekte). Alle setzten und setzen noch heute auf SwiftUI. Und als Entwickler, der noch Zeiten kennt, in denen es keine automatische Speicherverwaltung gab, kann ich voller Überzeugung sagen: SwiftUI erleichtert die App-Entwicklung massiv und ist eine Wohltat verglichen mit den Ansätzen von UIKit und der Arbeit mit Nib-Files und Storyboards. Und das galt auch schon in den Anfangszeiten von SwiftUI, in denen nervige Bugs und fehlende Dokumentation dem Entwicklungsprozess teils ziemliche Steine in den Weg legten. Ich war dabei, ich habe den Prozess mitgemacht und kann das daher auch ohne Scheuklappen mit Fug und Recht von mir geben.
Dass manch einer anno 2019 (und auch noch 2020 und 2021) den produktiven Einsatz von SwiftUI eher mied, kann ich vollends verstehen. Eher weniger verstehe ich, wie man heute noch SwiftUI verteufeln kann und es partout ablehnt. Technische Gründe per se gibt es da nicht mehr. Es scheint vielmehr strategisch eher extrem unklug, denn die Zukunft (und realistisch betrachtet auch schon die Gegenwart) gehört eindeutig SwiftUI. Die Konzepte hinter der Entwicklung von Apps für Apple-Plattformen stehen nicht still, und einzelne Aspekte wie Widgets zeigen bereits, dass bisweilen gar kein Weg an SwiftUI vorbeiführt. Eine Verweigerung von SwiftUI hat keine Zukunft und wirkt da eher persönlicher als technischer Natur.
SwiftUI ist anders (Gott sei Dank!)
Ein wenig fühlt es sich so an, als möchte sich so mancher Experte nicht von dem Know-How trennen, das er über Jahre hinweg bezüglich UIKit aufgebaut hat. Und sich im gleichen Zuge nicht mit den Konzepten auseinandersetzen, die SwiftUI mit sich bringt. Denn nichts ist schlimmer, als zu versuchen, das Paradigma von UIKit auf SwiftUI zu übertragen. Wer versucht, SwiftUI das UIKit-Korsett überzustülpen, wird weder Erfolg haben noch versteht er, warum SwiftUI überhaupt existiert.
Ich weiß, dass der gedankliche Umstieg von UIKit hin zu SwiftUI schwierig ist; ich bin selbst durch diesen Prozess durch und habe lange gebraucht, bis mir das SwiftUI-Paradigma in Fleisch und Blut übergegangen ist. Dafür schüttelte ich heute umgekehrt beinahe schon entsetzt den Kopf, wenn ich ältere Projekte auf UIKit-Basis sehe.
Noch nie habe ich schneller, produktiver und effizienter gearbeitet als mit dem Einsatz von SwiftUI. Es stimmt, was Apple sagt: SwiftUI nimmt den Entwicklern so viel unnötige Overhead-Arbeit ab und erlaubt es, den Fokus auf die Funktionalität der eigenen App zu richten. Und das ist kein Marketing-Gewäsch meinerseits, sondern schlicht und ergreifend die persönliche Erfahrung aus meinem Entwickler-Alltag.
Natürlich bleibt das Argument, dass SwiftUI heute nicht alle Funktionen abbilden kann, die UIKit und andere Apple-Frameworks mit sich bringen. Doch zum einen ist das umgekehrt genauso (Stichwort Widgets). Zum anderen ist das vollkommen egal. Denn die fehlenden Elemente lassen sich dennoch dank Reprasentables in SwiftUI einbinden, so denn man sie braucht.
Es stellt sich beim Einsatz von SwiftUI also nicht einmal eine endgültige entweder oder-Frage. Sowohl SwiftUI als auch UIKit können auf Wunsch koexistieren, was eine strikte Ablehnung von SwiftUI heutzutage noch verwirrender erscheinen lässt.
SwiftUI tut nicht weh. SwiftUI ist nicht böse. SwiftUI ist einfach anders. Und man muss entsprechend anders damit entwickeln. Ende der Geschichte.