Warum wir Swift und nicht SwiftUI bereitstellen

Seit 2019 wurde SwiftUI auf jeder WWDC ein Stück weiter vorangetrieben, und jedes Mal, wenn wir eine neue App in Angriff nehmen, setzen wir uns als Team zusammen und stellen uns dieselbe Frage: Hat es sich schon einen Platz in unseren Apps verdient? Bislang lautete die Antwort „Nein“ für die wichtigen Aspekte – und wahrscheinlich „Ja“ für die unwichtigen.

Das ist kein Urteil über SwiftUI im Allgemeinen. Viele Teams bringen damit hervorragende Apps auf den Markt. Es ist vielmehr eine Beschreibung dessen, wo es für uns Sinn macht: ein kleines Studio, das mehrere iPhone- und iPad-Apps gleichzeitig betreut, bei denen in keiner einzigen Platz für Überraschungen ist.

Was funktioniert

SwiftUI eignet sich wirklich hervorragend für statische Einstellungsbildschirme, Formularlayouts und alles, wo der View-Baum klein ist und der Datenfluss in eine Richtung verläuft. Wir nutzen es. Außerdem verwenden wir es für Vorschauen während des Designprozesses – der Iterationszyklus ist schneller als der von UIKit.

In der Praxis bedeutet das, dass der Bildschirm, auf dem man Einheiten auswählt oder Daten exportiert, oft auf SwiftUI basiert und in eine App eingebettet ist, deren Hauptbildschirme auf UIKit basieren. Beide koexistieren reibungslos nebeneinander, und durch ihre Kombination können wir die jeweiligen Stärken der beiden Technologien nutzen, anstatt die gesamte App einem einzigen Ansatz zu unterwerfen.

Was (für uns) nicht funktioniert

Sobald ein Bildschirm benutzerdefinierte Gesten, leistungskritische Listen, komplexe Navigationszustände oder präzises Animations-Timing erfordert, greifen wir wieder auf UIKit zurück. Der Grund dafür ist kein Hype – es sind die Fehler, die auftreten, wenn wir darauf verzichten. SwiftUI hat sich in den letzten Versionen deutlich verbessert, überrascht uns aber bei der Ausführung immer noch auf eine Weise, wie es UIKit selten tut.

Konkrete Beispiele helfen dabei. Bei einem Tipptrainer muss jeder Tastenanschlag ohne sichtbare Verzögerung zum richtigen Zeichen führen, und der Bildschirm muss mit den Fingern des Nutzers Schritt halten. Eine lange Historie von Einträgen in einem Tracker muss sich auf einem älteren Smartphone flüssig scrollen lassen. Ein Planer mit Drag-and-Drop-Funktion benötigt Gesten, die nicht mit den systemeigenen in Konflikt stehen. Bei solchen Bildschirmen haben wir festgestellt, dass UIKit vorhersehbarer ist.

Die Vor- und Nachteile

Das Festhalten an UIKit hat seinen Preis. Es bedeutet mehr Code für denselben Bildschirm, und es bedeutet, dass jeder, der neu einsteigt, sich mit einem älteren Framework auskennen muss, das in Tutorials zunehmend übersprungen wird. Einige neue Systemfunktionen erscheinen zuerst in SwiftUI, und ihre Übernahme aus UIKit erfordert zusätzlichen Aufwand. Wir müssen auch ehrlich zugeben, dass ein Teil unserer Zurückhaltung auf Vertrautheit zurückzuführen ist: Ein Framework gründlich zu kennen, ist zwar wertvoll, kann aber auch zu einer Ausrede werden.

Es gibt aber auch noch eine offene Frage. Unsere iPhone- und iPad-Apps laufen bereits auf Mac-Geräten mit Apple-Silicon, und native Mac-Apps sind in Planung. Sollte SwiftUI die gemeinsame Nutzung von UI-Code über diese Plattformen hinweg deutlich vereinfachen, könnte sich die Situation ändern.

Was wir falsch gemacht haben

Wir haben SwiftUI einmal für einen Bildschirm verwendet, der auf dem Papier einfach aussah, sich in der Praxis jedoch als alles andere als einfach erwies: eine Liste mit benutzerdefinierten Wischgesten und einem Status, der sich beim Scrollen änderte. In der Vorschau funktionierte alles einwandfrei, auf echten Geräten verhielt es sich jedoch seltsam. Die Neuprogrammierung in UIKit kostete mehr Zeit, als es gekostet hätte, von Anfang an mit UIKit zu arbeiten. Jetzt entscheiden wir von vornherein für jeden Bildschirm einzeln, je nachdem, was der Bildschirm tatsächlich leisten muss.

Das ist der einzige wirkliche Test: Wird uns das in der Produktion überraschen? Bei den meisten unserer Projekte kommt SwiftUI als Kerntechnologie nicht in Frage. Wir werden uns nächstes Jahr erneut damit befassen.