Unser mobiles Entwicklungsteam nutzt SwiftUI seit 2022 für die Entwicklung der App Infomaniak Mail für iOS. Heute ist es eines der größten Open-Source-Projekte, das zu 100 % in SwiftUI geschrieben wurde. Die Attraktivität des neuen Apple-Frameworks steht zwar ausser Frage, dennoch bleibt es für die Entwickler eine Herausforderung. Nur wenige Unternehmen trauen sich, es zu 100 % zu nutzen. Einerseits ist das Framework noch neu und verfügt bisher nur über eine unklare oder unvollständige Dokumentation. Andererseits müssen die erlernten Logiken grundlegend geändert werden. In diesem Artikel berichten die Entwickler von Infomaniak über ihre Erfahrungen bei der Einführung von SwiftUI für Infomaniak Mail.

Was spricht für die Verwendung von SwiftUI zur Einführung unserer speziellen Mail-App?

Wir wollten die App rasch weiterentwickeln und auf die neusten Features zurückgreifen können. SwiftUI ist die Grundlage für die nächsten Innovationen auf allen Apple-Plattformen: nicht nur auf iOS, sondern auch auf macOS und VisionOS.

Das neue Framework bringt Entwicklern mehrere Vorteile:

  • Dank der deklarativen Syntax lassen sich die Benutzeroberflächen übersichtlicher und prägnanter beschreiben.
  • Über das Vorschausystem können Sie Änderungen sofort sehen, ohne dass Sie hierfür kompilieren müssen.
  • Die Aufteilung der Bilder in wiederverwendbare Komponenten optimiert die Wartbarkeit der App.
  • Die Integration mit Swift ermöglicht es, die neuesten Sprachzusätze wie die FormatStyle-API direkt in Textfeldern zu verwenden.
  • Die Unterstützung von Internationalisierung und Barrierefreiheit erleichtert die Nutzung der App für alle, ohne dass hierbei, im Gegensatz zu UIKit, expliziter Code geschrieben werden muss.

Zieht man ein Fazit, so koexistiert der historische Ansatz mit UIKit noch sehr gut mit SwiftUI, aber wie lange noch? Wie man an vielen Beispielen sehen kann, stellt Apple sein neues Framework konsequent in den Vordergrund. Für die Implementierung von neuen Features in Betriebssysteme wird SwiftUI benötigt, wie dies bei Widgets oder Live Activities der Fall ist. Das neue Framework wird daher zu einem unverzichtbaren Bestandteil, um die neuesten Funktionen zu unterstützen. Wir wollten auch verhindern, dass die App auf einer zu schnell veralteten Technologie basiert.

SwiftUI Challenges vs. UIKit

Wenn unser Team heute auf SwiftUI geschult wird, hat es Fehler, Versuche und Verzögerungen erlebt, und zwar vor allem aus folgenden Gründen:

1. Gewährleistung der weiteren Unterstützung älterer Geräte

Um die geplante Obsoleszenz und den zu häufigen Austausch von Geräten zu begrenzen, sollten diese so lange wie möglich genutzt werden können. Wir bleiben freiwillig weiter bei SwiftUI 3, das mit iOS 15 ausgeliefert wurde, anstatt auf SwiftUI 5, das mit iOS 17 kam, umzusteigen, um die Geräte aller unserer Kunden mit iOS 15 zu unterstützen (ca. 5 % unserer Nutzer).

Diese Bereitschaft stellt jedoch eine Herausforderung für das mobile Team von Infomaniak dar: Das 2019 mit iOS 13 veröffentlichte Framework ist noch neu und entwickelt sich rasant weiter. Obwohl Apple die Lücken in SwiftUI im Laufe der Jahre schnell schliesst, schränkt die Unterstützung von iOS 15 die Nutzung neuer APIs ein.

2. Change Management

Die Umstellung auf SwiftUI wurde 2022 eingeleitet, als die Entwicklung eines POC mit UIKit bereits begonnen hatte. Damals hatten wir keine Erfahrungen mit dem neuen Framework mit unseren bestehenden Apps. Einige unserer Entwickler, die bereits durch aktive Technologiebeobachtung eigene Erfahrungen gesammelt hatten, ergriffen die Initiative bei den Best Practices und zogen andere mit sich.

Auch wenn das Umfeld vertraut war, mussten wir einen gewissen Widerstand gegen Veränderung überwinden und eine neue Vorgehensweise erlernen.

Wir haben uns entschieden, alles mit SwiftUI zu entwickeln. Jede neue Ansicht oder Komponente benutzte SwiftUI und die zuvor mit UIKit entwickelten Ansichten wurden nach und nach ersetzt, wenn sich die Modelle änderten und eine Entwicklung erforderten.
Philippe Weidmann, Tech Lead iOS – Infomaniak

Das Change-Management war die erste grosse Herausforderung für ein geschultes und mit UIKit vertrautes Team, denn die Entwicklungslogik ist mit SwiftUI grundlegend anders:

Mit der historischen UIKit-Methode (obligatorische Methode) wird die Anordnung und das Verhalten jedes Elements der Schnittstelle mit sehr detaillierten Vorgaben manuell gesteuert. Es muss definiert werden, wie die Ansichten und Bedienelemente zueinander und zu ihren Containern positioniert und dimensioniert werden sollen. Ausserdem muss die Logik aufgebaut werden, um auf verschiedene Ereignisse wie das Erfassen eines Feldes und die entsprechende Aktualisierung der Elemente reagieren zu können.

Mit dem neuen SwiftUI-Ansatz muss nur beschreiben werden, welche Ansicht mit den Zuständen und den Beziehungen zwischen den Elementen (deklarative Methode) angezeigt werden soll. Das Framework verwaltet automatisch das Layout und die Interaktionen entsprechend den Datenänderungen der App (reaktive Programmierung).

Letztlich ist SwiftUI effizienter und intuitiver, sobald man sich die Logik angeeignet hat.

Der Lernprozess besteht aus mehreren Phasen, wobei wir immer dazu tendieren, unsere Reflexe beizubehalten, wie z. B.:

  • SwiftUI wie UIKit schreiben (wir dachten, das wäre richtig).
  • Bevorzugte Nutzung von UIKit zur schnellen Problemlösung, anstatt von SwiftUI, was oft das Erlernen durch Tutorials erfordert.

Dann steigt die Lernkurve an. Mit UIKit haben wir die Kontrolle über jedes Detail. Dadurch wissen wir genau, was vor sich geht. Die einfache Nutzung von SwiftUI verbirgt hingegen die internen Mechanismen. Dadurch kann es passieren, dass bestimmte Anzeige- oder Performance-Probleme ohne gründliche Kenntnisse des Frameworks nicht erkannt werden können.

Daher setzte unser Team auf die Community, Forschung und unzählige Tests. Anhand der gewonnenen Erfahrungen konnten wir die einzuschlagenden Richtungen erkennen und Blockaden überwinden.

3. Reibungslose Nutzung und Performance

SwiftUI ist ein einfaches und schnell zu bedienendes, aber komplizierteres Framework für die Erstellung effizienter und optimierter Benutzeroberflächen. Die Optimierungen werden von Apple nicht unbedingt gut dokumentiert.

In unserem Fall muss sich die App Infomaniak Mail bei Benutzern mit 12 E-Mails in ihrem Posteingang genauso verhalten wie bei Benutzern mit 50 000 E-Mails. Gleiches gilt für Kontakt-Avatare, die in allen Diskussionen flüssig angezeigt werden müssen, unabhängig von der Anzahl der Teilnehmer. Das war nicht der Fall.

Wie wir weiter unten erklären, haben wir erkannt, dass es Dinge gibt, die wir mit diesem Framework nicht machen sollten. Allerdings müssen die Informationen erst einmal vorhanden sein.

4. Individuelle Anpassung der App: Anforderungen in Bezug auf UI/UX

Infomaniak setzt auf allen Plattformen (Android und iOS) auf eine eigene, konsistente visuelle Identität, auch wenn sie sich von den Konventionen von Apple immer stärker unterscheiden.

SwiftUI erlaubt gelegentlich nicht die Anpassung der Komponenten und bietet nur wenige Optionen. Apple drängt die Entwickler gewissermassen dazu, das Design-System von Apple zu verwenden, d. h. das Look and Feel, das in nativen Apps wie Mail oder Reminders zu finden ist.

Wir mussten mehrmals eigene Komponenten erstellen, denn wir konnten die zur Verfügung gestellten nicht verwenden. Manchmal mussten wir sogar gegen das Framework ankämpfen, um unsere Ziele zu erreichen. Bei Verwendung der nativen Mechanismen zeigen die Apps beispielsweise den Titel der Ansichten (hier den Namen des Ordners Posteingang für die Mail-App) zentriert an. Die App Infomaniak Mail muss ihr eigenes System zur Anzeige des Titels verwenden:

Anzeige des Titels für Infomaniak Mail
Anzeige des Titels in einer nativen App (hier Mail)

Um das Verfassen von E-Mails zu vereinfachen, verfügt unsere App über den Button „Neue Nachricht“, den sogenannten schwebenden Button. Im iOS Designsystem gibt es ihn nicht, sondern eher in Android-Apps. Wir mussten ihn von Grund auf entwickeln.

Dieser Button muss auch automatisch eingeklappt werden, damit der Benutzer beim Scrollen seine Mailliste einsehen kann. Bei dieser technischen Herausforderung muss man wissen, wann der Benutzer durch die Liste scrollt, und SwiftUI bietet hierfür keinen einfachen Mechanismus.

Schwebender Button ausgeklappt
Schwebender Button eingeklappt

Die App Infomaniak Mail ermöglicht dem Benutzer auch, E-Mails durch längeres Drücken auszuwählen, um mehrere Nachrichten zu bearbeiten. Diese Mechanik wird von SwiftUI nicht nativ angeboten, da sie von den Standards von Apple abweicht. Also haben wir alles selbst erstellt.

Bei der individuellen Anpassung mussten wir lernen, die von Apple vorgesehenen Szenarien zu übertreffen.

SwiftUI vereinfacht das Erstellen von Komponenten und die Iteration über das Design, aber die Anpassung bleibt schwierig. Für Komponenten erfordert UIKit mehr Zeit und ist verbaler, aber die Anpassung ist viel einfacher.
Philippe Weidmann, Tech Lead iOS – Infomaniak

Implementierung der Hauptkomponenten der App Infomaniak Mail mit SwiftUI

Drei Hauptkomponenten der Mail-App stellten SwiftUI-spezifische Herausforderungen dar:

1. Die E-Mail-Liste: der Teil, der am meisten Performance verlangt

Die E-Mail-Liste ist ein zentraler Punkt für das Nutzererlebnis. Sie kann eine grosse Menge an Elementen in verschiedenen Darstellungsmodi enthalten (kompakt, Standard, vollständig). In der Praxis bewahren einige Benutzer alle E-Mails in einem Ordner auf. Daher müssen wir sicherstellen, dass die Navigation immer flüssig und leistungsfähig bleibt, egal wie viele E-Mails sich in der Liste des Nutzers befinden.

Apple lässt in seiner Dokumentation vermuten, dass die Verwendung der SwiftUI-Komponente „List“ einfach sein sollte: Jedes Element aus unserer Liste wird einfach angezeigt. Theoretisch sollte sich der Entwickler keine weiteren Fragen stellen.

Die wirklichen Zusammenhänge sind allerdings komplizierter. Wenn es viele Elemente gibt, können die Einschränkungen eines Smartphones die Performance beeinträchtigen. In iOS sind seit jeher integrierten Mechanismen vorhanden, um lange Listen anzuzeigen, ohne dabei die schnelle Darstellung zu beeinträchtigen. Man spricht von der Wiederverwendung von Zellen in einer Liste, wenn das System nur die auf dem Bildschirm sichtbaren Elemente anzeigt und die Elemente nach und nach wiederverwendet, wenn sie auf dem Bildschirm eingeblendet und ausgeblendet werden. SwiftUI verbirgt diese Mechanismen vor den Entwicklern und das Framework sorgt aus Gründen der Einfachheit für die Wiederverwendung der Zellen.

So, wie wir unsere Liste ursprünglich implementiert hatten, konnte SwiftUI die Wiederverwendung der Elemente nicht korrekt gewährleisten und die Unterschiede bei einer Änderung nicht berechnen. Konkret konnte es passieren, dass eine Liste mit 50 000 E-Mails auf älteren Geräten erst nach mehr als einer Sekunde angezeigt wurde und der Rest der Benutzeroberfläche deutlich verlangsamt wurde. Die Dokumentation der List-Komponente lieferte keine Erklärung für dieses Problem.

Performance-Probleme sind bei SwiftUI ein Dauerthema. In der Entwicklerdokumentation wurde nicht explizit erwähnt, wie sich die Verwendung eines Flow-Controllers direkt in einer Liste auf die Performance auswirkt. Nur dank der Tipps in einem kurzen Video (Demystify SwiftUI Performance) für die WWDC 2023 konnten wir unsere Probleme lösen und die Performance deutlich verbessern.

Die Dokumentation von Apple ist in der Regel von guter Qualität, aber wir empfehlen Entwicklern dringend, die Videositzungen der WWDC zu verfolgen, denn sie bieten viele interessante Informationen und sind sehr gut produziert. Ausserdem ist alles kostenlos erhältlich.

2. Das Verfassen einer Nachricht

Das Verfassen von Nachrichten setzt sich aus folgenden zwei Hauptelementen zusammen:

  • Die Kopfzeile (in der die Empfänger und der Betreff der Mails angegeben werden)
  • Der Nachrichtentext (eine Webansicht)

In der Kopfzeile schlägt die Mail-App Kontakte mit dem angezeigten Namen und dem angezeigten Avatar vor. Wird der Kontakt ausgewählt und bestätigt, wird der Name des Kontakts in eine Komponente namens „Chip“ (kleiner Button) umgewandelt und in die Empfängerliste aufgenommen. Wird dieser Chip vom Benutzer aktiviert, zeigt er einen Dialog zum Löschen des Empfängers an. Diese Elemente sind typischerweise von SwiftUI nicht vorgesehen und machten daher eine massgeschneiderte Entwicklung notwendig.

Im Nachrichtentext verfasst der Benutzer seinen Text in einer Webansicht. Das heisst, er schreibt eine HTML-Seite, ohne es zu merken. Auf der Entwicklerseite müssen wir die Verbindung zwischen dem Inhalt der Nachricht, wie sie in der Webansicht angezeigt wird, und dem, was am Ende vom Server an den Empfänger gesendet wird, herstellen.

Das Verfassen einer neuen Nachricht ist einer der wichtigsten Einstiegspunkte in eine E-Mail-App. Hierbei handelt es sich um einen Reibungspunkt, der für die Benutzererfahrung von Bedeutung sein kann. Da die mobile Webansicht eine ziemlich umfangreiche Komponente ist, wird unser Team in diesem Jahr von Grund auf einen neuen Container entwickeln, um eine bessere Performance zu erzielen.
Philippe Weidmann, Tech Lead iOS – Infomaniak

3. Das personalisierte Seitenmenü

Ebenso wie der schwebende Button „Neue Nachricht“ ist auch das seitliche Sliding-Menü, das sich durch Tippen auf den Hamburger-Button oben links aufklappen lässt, auf Apple-Plattformen keine übliche Komponente. Vielmehr ist es ein Element des „Material Design“ von Google (Android). Es basiert auf einer Bibliothek, mit der sich das Verhalten der Elemente auf allen Geräten optimieren und vereinheitlichen lassen. Aber je nachdem, wie man dieses Sliding-Menü mit SwiftUI entwirft, kann es auch eine sehr schlechte Performance haben. Wir mussten es von Grund auf neu entwickeln, um das gleiche Look and Feel zu erhalten.

Diese Anpassungen erfordern per se eine spezifische Entwicklung, führen aber auch auf Dauer zu mehr Arbeit.

Da wir viele nicht von SwiftUI geplante Komponenten erstellt haben, müssen wir diese Ergänzungen immer auf andere Plattformen wie iPadOS und evtl. macOS übertragen. Anpassungen, die nicht nötig gewesen wären, wenn wir das Apple-Framework genau eingehalten hätten, ohne unser eigenes Design-System zu integrieren. Neue Plattformen wie VisionOS regen zum Nachdenken an, da sich hier die Anpassung unserer Personalisierungen komplexer gestaltet.

Normalerweise lässt sich ein Seitenmenü von der linken Seite des Bildschirms aus öffnen oder schliessen, indem der Benutzers es mit dem Daumen zieht. Da keine native SwiftUI-Komponente für dieses Verhalten existiert, musste diese Ansicht von Grund auf implementiert werden. Konkret bedeutet dies, dass die Menüansicht über die Hauptansicht gelegt und nach links verschoben wird, bis sie unsichtbar ist, um sie auszublenden, und umgekehrt, um sie einzublenden.

Ursprünglich war der Menüinhalt nicht vom Menücontainer selbst getrennt, was zu grossen Performanceproblemen führte. Denn bei jeder Änderung der Menüverschiebung (d. h. jedes Pixel der Animation nach links oder rechts) wurde die gesamte Ansicht neu gezeichnet. Bei einem neueren Smartphone war die Verlangsamung nicht zu bemerken, verbrauchte aber nach unseren Kriterien zu viel CPU. Bei einem älteren Smartphone war die Verlangsamung für den Benutzer erkennbar.

Der erste Schritt bestand daher darin, das Problem mit Instrumenten zu identifizieren und zu messen, um sicherzustellen, dass die vorgenommenen Änderungen eine echte Verbesserung brachten.

Dann haben wir die Ansicht, die das Menü (den Container) enthält, vom Inhalt selbst getrennt. Dadurch muss das SwiftUI-Framework nur den Container neu zeichnen und kann den Inhalt unberührt lassen, was die Performance enorm steigert.

Bilanz der Umstellung von UIKit auf SwiftUI

Was wäre, wenn wir es noch mal machen müssten? Wir würden uns wieder für SwiftUI entscheiden, aber wir würden verstärkt Schritt für Schritt vorgehen.

Im Nachhinein war es ziemlich gewagt und sogar schmerzhaft, in einem Schritt von 100 % auf SwiftUI zu wechseln.

Ich waranfangs eher dagegen, die App Infomaniak Mail vollständig in SwiftUI zu entwickeln. Es war eine schwierige Entscheidung, aber heute, wenn wir es noch einmal machen müssten, würden wir es wieder tun. Das verschafft uns einen grossen Vorteil gegenüber der Wartung und Weiterentwicklung der App in der Zukunft.
Joris Bodin, Developer Team Leader – Mobile und Desktop

Die Vorteile von SwiftUI sind deutlich erkennbar, wenn wir wieder an unseren älteren Apps arbeiten, die in UIKit geschrieben wurden. Ein UIKit-ViewController, der eine Liste verwaltet, hat schnell mehrere hundert Zeilen, die geschrieben und gepflegt werden müssen, während einige SwiftUI-Zeilen ausreichen könnten.

Bei der Entwicklung in SwiftUI konzentriert man sich hauptsächlich auf die Daten, die angezeigt werden sollen, während UIKit eine Menge Coating benötigt, um zu erreichen, was man will.

SwiftUI ist die Zukunft. Das Framework bringt entscheidende Neuerungen mit sich, wie die Live-Vorschau der App in der Entwicklungsoberfläche. Historisch gesehen hat Apple gezeigt, dass es, wenn es eine Spitzentechnologie wie SwiftUI anbietet, diese auch über die Zeit hinweg beibehält. Wir wissen also, dass unsere Bemühungen wahrscheinlich nicht in drei Jahren überholt sein werden, im Gegensatz zu Google, das zwar mehr Neues anbietet, es aber auch schneller wieder fallen lässt. In diesem Punkt wird das SwiftUI-Pendant auf Android, JetPack Compose, von einem anderen Unternehmen als Google vorangetrieben, nämlich JetBrains. Wir sind der Meinung, dass dies JetPack Compose eine grössere Chance für die Zukunft gibt.

Auch wenn UIKit noch lange nicht veraltet ist und in vielen Fällen eine gute Option bleibt, setzt sich SwiftUI allmählich von selbst durch. Es vereinfacht die Entwicklung und Zukunft der Apple-Plattformen. Auch wenn der Sprung ins kalte Wasser Angst machen kann, sollte man nicht zögern.
Valentin Perignon, iOS-Entwickler bei Infomaniak

Eine der grössten Herausforderungen für uns war: „Wie kann ich eine eigene Identität entwickeln und gleichzeitig die Apple-Richtlinien einhalten?“ Wir haben gesehen, dass das, was nicht im Framework vorgesehen ist, zu höherem Arbeitsaufwand führt.

Unsicheren Entwicklern möchten wir empfehlen, hier Schritt für Schritt vorzugehen. Eine Lehre aus dieser Erfahrung ist, dass 2wenn Sie es kompliziert finden, dann tun Sie wahrscheinlich etwas Falsches“.

Die SwiftUI-Dokumentation deckt nicht alles ab und wir mussten selbst nach Antworten suchen, insbesondere bei der Performance. Wir empfehlen Ihnen, sich die Videos der Online-Konferenzen (WWDC) von Apple anzuschauen, die wichtige Informationen enthalten, um eventuell bei Problemen eine Lösung zu finden.

Bei unseren anderen Apps wurde kDrive ursprünglich auf iOS 12 mit UIKit entwickelt, weil SwiftUI erst ab iOS 13 mit fehlenden Komponenten verfügbar war. Da wir SwiftUI zum damaligen Zeitpunkt nicht nutzen konnten, können wir Komponenten von kDrive in der App Infomaniak Mail nicht wiederverwenden. Wir beabsichtigen gerade, nach und nach auf SwiftUI zu migrieren, da wir aus unseren Erfahrungen mit der Mail-App gelernt haben.

Aus beruflicher Sicht ist die Beherrschung einer Spitzentechnologie wie SwiftUI auf dem Arbeitsmarkt sehr wertvoll. Trotzdem empfehlen wir jungen Entwicklern, sich mit UIKit vertraut zu machen, da viele Firmen diese Umstellung noch nicht vorgenommen haben. SwiftUI ist eine neue, „trendige“ Technologie, die derzeit nur wenige beherrschen, und wir freuen uns, dass wir nun dazugehören.

Mehr erfahren