Meetup-Interview: Einführung in SwiftUI & Combine

Unseren Max kennt ihr bestimmt schon aus seinen Blogposts zu SwiftUI & Combine – er ist bei uns einer der Köpfe unserer Mobile-Teams. In Kürze wird er sein Wissen rund um die beiden Frameworks in seinem Remote-Meetup Einführung in SwiftUI & Combine mit euch teilen; genauer gesagt am Dienstag, den 19. Mai.

In Vorbereitung auf dieses Meetup haben wir mit über seine Erfahrungen mit den Frameworks gesprochen. Außerdem erzählt er euch, wie es seiner Meinung nach um die Einarbeitungszeit steht – und warum es bei SwiftUI noch ein wenig hakt.

Infos und Anmeldung zum Meetup

Wie bist du zu SwiftUI und Combine gekommen?

Ich fand iOS-Entwicklung schon länger spannend bzw. mache ich das auch in meinen Projekten, unter anderem auch in dem jetzigen. Auf SwiftUI und Combine bin ich gekommen, weil Apple einmal im Jahr bei der WWDC neue Frameworks vorstellt.

Erst hatte ich mir SwiftUI angeschaut, was meiner Meinung nach super ist, weil es ein riesengroßer Fortschritt zum bisherigen Stand ist. In der UI-Entwicklung bei Apple hat man sowohl ein UI-Interface (welches leider seine Limits hat), als auch die Möglichkeit, Sachen per Code zu machen. Meistens braucht man beides, hat dann aber Schwierigkeiten bei der Integration. SwiftUI vereint das schön und hat dabei viel Ähnlichkeit zu der User-Interface-Entwicklung in Android oder bei der Webentwicklung.

Combine ist ein gutes Framework, um asynchronen Code lesbarer und weniger fehleranfällig zu schreiben.

Max

Combine habe ich mir dann angeschaut, weil ich mich mit einem Kumpel (der auch iOS-Entwicklung macht) darüber ausgetauscht habe, dass es mir bei SwiftUI umständlich erschien, die User- und Netzwerk-Events zu verarbeiten. Daraufhin hat er mich auf Combine aufmerksam gemacht, was eine wunderbare Ergänzung darstellt und hierzu sehr gut passt. Natürlich habe ich mir das dann auch mal angeschaut. 

Combine ist eigentlich noch viel weiterentwickelter als SwiftUI, also ein sehr viel reiferes Framework. Und es ist tatsächlich ein sehr cooles Tool, um asynchronen Code lesbarer und weniger fehleranfällig zu schreiben. 

Also wenn man sich für native App-Entwicklung interessiert, ist es auf jeden Fall sehr interessant – auch um seinen Horizont zu erweitern und in modernere Programmier-Paradigmen reinzuschauen.

Warum arbeitest Du gerne damit? 

Da würde ich gerne erst etwas zu Combine sagen. Generell bin ich ein großer Fan von modernen Programmierparadigmen und weniger von Objektorientierung u.s.w. Combine nutzt viele funktionale Elemente und ist auch deklarativ. Das heißt, ich schreibe einfach für ein Event, also ein User-Input oder ein Nutzer-Request, ein „Wie dieser zu handhaben ist“ und dann wird das gleich schön für alle gemacht. Ich muss dadurch nicht mehr imperativ schreiben „Wenn das passiert, dann soll das passieren“, sondern schreibe einfach deklarativ 2das ist der Zustand mit der Transformation“. Dadurch habe ich Code, der einfacher lesbar ist und bei dem es schwerer ist, Fehler einzubauen. Und das ist schließlich immer gut.  

SwiftUI ist im Prinzip vom Paradigma her ähnlich wie Combine – und einfach viel besser als UIKit.

Max

SwiftUI ist im Prinzip vom Paradigma her ähnlich und ist einfach viel besser als UIKit. Der Code an sich ist wenig, wenn man schnell ein User Interface bauen möchte. So haben wir es zum Beispiel auch bei unserer PayForMe-App gemacht. Wenn man auf Standardelemente zurückgreift, kann man den Code einfach herunter schreiben und hat somit das User Interface viel schneller geschrieben.

Wenn man bestimmte Formatierungen machen möchte, kann man die auch einfach einbauen, das ähnelt dann sehr CSS, also dem Web-Bereich. Man modifiziert das dann einfach dementsprechend intensiv gegenüber dem Default-Style – der an sich auch schon gut aussieht – bis man dann irgendwann den Style hat, den man haben möchte. Diesen kann man dann auch weiter vererben; von einer View zu einer anderen dazugehörigen View.    

Wie lange muss man sich in SwiftUI und Combine einarbeiten, um sie anwenden zu können? 

Das kommt darauf an …

An sich ist das Schwierigste, wenn man hauptsächlich – wie ich – imperative Programmierung gewohnt ist, sich in das Deklarative einzudenken. Wenn man sich mit funktionaler Programmierung auskennt ist es deutlich einfacher, vor allem bei Combine.

Ich würde sagen: um es mal in kleineren Bereichen auszutesten, würde das schon schnell in ein paar Tagen gehen. Wenn man größere Projekte vollständig damit bearbeiten möchte, braucht man schon eher ein paar Wochen, in denen man sich richtig einarbeitet.

Bei SwiftUI dauert es leider auch noch einmal deutlich länger als bei Combine. Denn SwiftUI ist noch ziemlich verbugt und neu. Da gibt es noch viel unerwartetes Verhalten und es ist einfach noch nicht ganz fertig. Wodurch es auch schwieriger wird, dann mit den ganzen Kinderkrankheiten klarzukommen. 

Gibt es auch Dinge an den beiden Frameworks die Dich stören bzw. die Du nicht magst? 

Bei SwiftUI auf jeden Fall die Unfertigkeit. Es gibt manche Sachen, die es bei UIKit (das ist das Vorgänger-Framework, das momentan für die User-Interfaces von Apps in der iPhone-Welt verwendet wird) gibt, aber bei SwiftUI noch nicht. Das heißt, dass man teilweise nochmal auf UIKit-Komponenten zugreifen muss.

Um es in kleineren Bereichen auszutesten hat man sich schnell eingearbeitet – bei größeren Projekten braucht man eher ein paar Wochen.

Max

Zudem funktionieren die Compiler Warnings noch nicht richtig bzw. wird oft zwar irgendein Compiler-Fehler angezeigt, aber nicht der, der gerade vorhanden ist. Es wirkt daher generell alles sehr unfertig. Nichtsdestotrotz kann man es schon erfolgreich einsetzen, wenn man die Limitierungen bzw. Macken kennt.

Bei Combine ist es schwieriger zu sagen. Ich glaube, wenn man sich mit Combine auf zu simple Sachen stürzt, läuft man Gefahr, dass man das deutlich komplizierter macht, als man es machen müsste. Also man kann sich mit Combine – wenn man es falsch einsetzt – die Situation deutlich verkomplizieren.