Protons neue mobile Mail-Apps: Da steckt mehr dahinter, als man sieht

Im September letzten Jahres haben wir ein großes Update von Proton Mail für iOS und Android veröffentlicht.

Oberflächlich betrachtet bieten die neuen Apps ein modernes Design, bessere Leistung und Offline-Fähigkeiten – aber es steckt viel mehr dahinter, als man sieht. Hinter den Kulissen sind die Apps eine komplette Neuentwicklung von Proton Mail auf einem neuartigen Technologie-Stack, ein Projekt, das intern unter dem Namen Engineering Transformation läuft. Der Begriff neuartig ist bewusst gewählt, denn – nach bestem Wissen und Gewissen – ist dies das erste Mal, dass die gewählte Technologie im Kontext einer etablierten Produktionsanwendung verwendet wurde.

Dieser Artikel soll Licht auf die faszinierende Reise werfen, die unser Team bei der Umsetzung dieser Revolution durchlaufen hat, und einige der Fragen beantworten, die uns unsere Community auf dem Weg gestellt hat. In erster Linie ist der Grund dafür die Notwendigkeit, den Status quo zu ändern.

Wie alles begann

Die Erkenntnis, dass sich Dinge ändern mussten, traf uns an einem Freitagabend im Oktober 2023. Sie materialisierte sich mit überraschender Klarheit, aber nicht aus heiterem Himmel: Es war der Höhepunkt von Monaten, die damit verbracht wurden, einen gemeinsamen Nenner für die scheinbar unzusammenhängenden Probleme zu finden, die die Erfahrung unserer Benutzer mit den Mobilprodukten Mail und Calendar beeinträchtigten.

Auf die Gefahr hin, zu vereinfachen, können wir die Schmerzpunkte in drei Bereichen zusammenfassen:

• Qualität: Mail iOS und Mail Android, isoliert betrachtet, blieben hinter den Erwartungen in Bezug auf Qualität und Leistung zurück.
• Funktionslücke zwischen iOS und Android: Einige Funktionen waren nur auf einer Plattform verfügbar, ohne Klarheit darüber, wann die andere aufholen würde.
• Entwicklungsgeschwindigkeit: Wichtige Updates und lang erwartete Funktionen wurden nicht rechtzeitig auf beiden Plattformen bereitgestellt.

Einige der Probleme gingen über den Mobilbereich hinaus, und ihre Beantwortung würde einen Exkurs vom Technologiebereich in den faszinierenden Problemraum der organisatorischen Skalierung erfordern, insbesondere bei schnell wachsenden Tech-Start-ups. Aber die Zerbrechlichkeit des mobilen Ökosystems war sehr stark in Technologie und Architektur verwurzelt.

Skalierung der mobilen Entwicklung

Die Skalierung der mobilen Entwicklung bringt eine einzigartige Reihe von Herausforderungen mit sich, die sich deutlich von der Skalierung von Backend- und Web-Teams unterscheiden. Diese Unterschiede ergeben sich aus der Plattformfragmentierung und den operativen Realitäten des mobilen Ökosystems. Mobile Teams müssen in der Regel mehrere Plattformen über eine Vielzahl von Betriebssystemen und Geräten (Telefone, Tablets, manchmal Wearables) unterstützen. iOS und Android kommen mit ihren eigenen Programmiersprachen, Frameworks und Tools, was zu großen Mengen an doppeltem Aufwand führt: mehrere Teams, doppelte Codebases und ständige Kompromisse zwischen plattformspezifischer und produktbezogener Arbeit. Das Produktangebot synchron zu halten, erfordert einen enormen Koordinationsaufwand.

Was eine branchenweite Herausforderung ist, war für Proton besonders akut. Funktions-Apps wie Mail und Calendar sind von Natur aus komplexer als die meisten mobilen Anwendungen auf dem Markt. Wenn man die zusätzliche Schicht der Client-Logik hinzufügt, die für die Handhabung der Ende-zu-Ende-Verschlüsselung erforderlich ist, erhält man besonders „dicke“ Clients. Damals war das Android-Team damit beschäftigt, Mail neu zu schreiben, um bessere Qualitätsstandards zu erreichen – eine Investition, die gut 18 Monate dauerte. iOS brauchte ebenfalls dringend eine neue Architektur, ganz zu schweigen von Calendar. Die Kosten der Duplizierung zehrten an all unseren Entwicklungsressourcen, und es wurde klar, dass wir nicht erfolgreich sein würden, wenn wir mehr vom Gleichen tun.

Das Beste daran, zu erkennen, dass man feststeckt, ist, dass es als Zwangsfaktor wirkt, außerhalb der Einschränkungen des aktuellen Status quo zu denken. Was würden wir tun, wenn wir neu anfangen könnten, befreit von der Last der Entscheidungen und Verpflichtungen, die uns hierher geführt haben? Wenn man sich genauer ansieht, wie erfolgreiche Unternehmen dieses Problem im letzten Jahrzehnt angegangen sind, stellt man fest, dass sie einer von nur zwei möglichen Strategien gefolgt sind:

1. Sie haben Geld auf das Problem geworfen und immer größere Teams aufgebaut, da hohe Betriebskosten durch eine Kombination aus bodenlosen Investitionen und/oder üppigen Renditen ausgeglichen wurden. Dies war keine Option für Protons VC-freies Geschäftsmodell: Wir können nicht mit den Ausgaben von werbefinanzierten, investorengestützten Wettbewerbern konkurrieren.
2. Sie haben ihre Apps neu entwickelt, um die Verschwendung loszuwerden, was bedeutet, Apps (so weit wie möglich) unter Verwendung einer gemeinsamen Codebasis zu bauen.

Da Option 1 nicht in Frage kam, war der Weg nach vorne vorgezeichnet.

Ein Mittel zum Zweck: Die Wahl des richtigen Tech-Stacks

Der nächste Schritt war die Wahl eines Tech-Stacks, der die Aufgabe tatsächlich erfüllen konnte.

In den letzten 15 Jahren wurde die plattformübergreifende mobile Entwicklung mit „One-Size-Fits-All“-Lösungen überschwemmt: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform und viele andere. Jede kam mit demselben Versprechen – die native Entwicklung vollständig zu ersetzen. In der Praxis scheiterten die meisten entweder ganz oder waren nur in eng begrenzten Problemräumen erfolgreich. Es gibt keine universelle Abstraktion, die Plattformunterschiede verschwinden lässt: Jeder, der große mobile Anwendungen ausgeliefert und gewartet hat, weiß das. Der einzige zuverlässige Weg nach vorne ist, von konkreten Anforderungen rückwärts zu arbeiten, anstatt von Tooling-Trends vorwärts.

Wir haben dieses Endziel in eine Reihe nicht verhandelbarer Anforderungen (1) übersetzt, die jede gewählte Lösung erfüllen musste, und nutzten sie als unseren leitenden Rahmen während des Bewertungsprozesses:

1. Kosten und Zeitrahmen: Der Stack musste die Kosten und die Zeit, die für die Bereitstellung, Wartung und Weiterentwicklung von Proton Mail auf iOS und Android erforderlich sind, wesentlich reduzieren.
2. Benutzererfahrung: Sie musste eine nahezu native Leistung und Interaktionsqualität bewahren – alles weniger war ein Ausschlusskriterium.
3. Strategische Zukunftssicherheit: Die Lösung musste langlebig sein. Wir haben bewusst Frameworks von Drittanbietern vermieden, die unsere Roadmap von der fortgesetzten Unterstützung eines anderen Anbieters abhängig machen würden.

Die Spannung zwischen den ersten beiden Einschränkungen ist die Version des Heiligen Grals der Branche: „Eine plattformübergreifende Lösung, die die Leistung und Benutzererfahrung nativer Anwendungen liefert.“

Wir waren von Anfang an skeptisch, dass React Native oder Flutter – die beiden dominierenden plattformübergreifenden Frameworks zu dieser Zeit – diese Messlatte erfüllen könnten. Dennoch haben wir diese Skepsis validiert, indem wir Proof-of-Concept-Implementierungen der Nachrichtenlistenansicht von Mail bauten.

React Native offenbarte schnell seine Grenzen. Das Scrollen durch einen großen Datensatz machte die Kosten seines interpretierten Ausführungsmodells schmerzlich deutlich. Flutter schnitt besser ab, aber die Benutzeroberfläche blieb sichtbar nicht nativ, insbesondere auf iOS. Wichtiger noch, Flutter ist ein proprietäres Framework, das von Google kontrolliert wird, das eine Geschichte(neues Fenster) hat, interne Technologien aufzugeben, und kürzlich einen großen Teil des Flutter-Teams entlassen hatte. Für ein Produkt mit langfristigen Sicherheits- und Zuverlässigkeitsgarantien war dieses Maß an externer Abhängigkeit inakzeptabel.

Kotlin Multiplatform war der nächste Kandidat. Es ist eine überzeugende Option – insbesondere für Organisationen mit tiefgehender Android-Expertise –, aber es blieb letztendlich hinter unserem Anwendungsfall zurück. Das Fehlen einer gemeinsamen UI-Schicht, Fragen zur Reife und der zusätzliche Overhead, der durch sein Ausführungsmodell eingeführt wurde, überwogen seine Vorteile.

An diesem Punkt war die Schlussfolgerung klar und im Einklang mit unserer anfänglichen Intuition: Die einzige Architektur, die dem gewünschten Ergebnis konsequent nahe kommt, ist ein bewusst gemischter Stack. Native UI auf jeder Plattform – Jetpack Compose auf Android, SwiftUI auf iOS – unterstützt durch eine gemeinsame Geschäftslogikschicht, die in einer leistungsstarken Low-Level-Sprache geschrieben ist. Dieser Ansatz hat eine Erfolgsbilanz: Dropbox verwendete bekanntermaßen C++, um Geschäftslogik über mobile Plattformen hinweg zu teilen, bevor es 2019 aufgrund der operativen und kognitiven Kosten der Sprache aufgegeben wurde.

Ende 2023 hatte sich Rust klar als Nachfolger in der Abstammungslinie der Systemprogrammiersprachen herauskristallisiert.

Rust besetzt denselben Leistungsumfang wie C++, aber ohne viele seiner historischen Altlasten. Es bietet starke Speichersicherheitsgarantien ohne Garbage Collection, erzwingt Thread-sichere Nebenläufigkeit zur Kompilierzeit und wird von einem großen, hochkompetenten Open-Source-Ökosystem unterstützt. Genauso wichtig ist, dass sich Rust sauber in native mobile Sprachen integriert – Swift und SwiftUI auf iOS, Kotlin und Jetpack Compose auf Android –, was es zu einer pragmatischen Wahl für das Teilen von Kernlogik macht, ohne die UI-Schicht zu gefährden.

Dies war keine risikofreie Entscheidung. Zu der Zeit gab es nur wenige Beispiele für groß angelegte, verbraucherorientierte mobile Anwendungen, die auf einer Rust-zentrierten Architektur basierten, und die Rust-Erfahrung im Team war begrenzt.

Aber bedeutsame Innovation geschieht selten in risikoarmem Gebiet. Die wirkliche Herausforderung war nicht Rust selbst, sondern die organisatorische Trägheit – der Wechsel von bewährten, konservativen Ansätzen hin zu bewusstem Experimentieren, geleitet von klaren Einschränkungen und technischem Urteilsvermögen.

Das neue Proton Mail: Ergebnis und Erkenntnisse

Spulen wir vor bis heute und sehen wir uns an, wie das Wagnis ausgegangen ist.

Das Diagramm unten stellt die Architektur von Mail Mobile dar. Der Rust-Kern ist für die Gesamtheit der Geschäftslogik der Anwendung verantwortlich. Wir haben die Nutzung von Rust über seine üblichen Anwendungen (Netzwerk, Speicher, algorithmische Berechnung) hinaus bis in die Handhabung komplexer Navigationslogik vorangetrieben. Ein typisches Beispiel ist die Logik, die das unendliche Scrollen der Nachrichtenliste steuert. Obwohl unorthodox, erwies sich dies als Schlüssel zur Erreichung unseres Ziels, die Wiederverwendung von Code zu maximieren. Infolgedessen wird fast 80 % der Codebasis jetzt zwischen iOS und Android geteilt.

Hat sich dies in eine schnellere, qualitativ hochwertigere Markteinführung übersetzt? Während es für ein endgültiges Urteil noch zu früh ist, waren die ersten Anzeichen sehr ermutigend:

• In den zwei Monaten nach der Veröffentlichung gelang es dem Team, einen wöchentlichen Rhythmus von Funktionsupdates auf beiden Plattformen aufrechtzuerhalten (insgesamt 12 Funktionsfreigaben).
• Wir haben die Funktionslücken zwischen den Plattformen geschlossen und lang erwartete Funktionen wie „Später lesen“, Kalender-RSVP und „Swipe-to-Next-Message“ auf Android gebracht.
• Selbst in diesem frühen Stadium hat sich die neue Codebasis als stabiler als frühere Generationen auf beiden Plattformen erwiesen: Die Absturzrate unter iOS liegt bei 0,05 % (runter von 0,12 %), während die von Android wieder auf einem historischen Basiswert liegt (0,19 %). Dies ist eine starke Bestätigung für die Laufzeitstabilität von Rust.

Support skaliert unter diesem Ansatz ebenfalls effektiver. Es ist oft schneller, eine einzelne, gemeinsame Ursache zu identifizieren und zu beheben, als oberflächlich ähnlichen Problemen nachzujagen, die aus leicht unterschiedlichen Logikfehlern resultieren, die über zwei unabhängige Codebases verteilt sind. Wir fanden eine empirische Bestätigung dessen, was zuvor eine Arbeitshypothese war, als wir eine Klasse von Kategoriesynchronisierungsproblemen behoben, die die Logik betrafen, die die Offline-Fähigkeiten der App untermauert: eine Ursache, eine Lösung – dargestellt im Diagramm oben durch das mit Version 7.6.2 ausgelieferte Rebasing-Modul.

Die Kehrseite der Medaille?

• Fehler und Regressionen haben wahrscheinlich breitere Auswirkungen und betreffen Benutzer auf beiden Plattformen. Man kann nicht wirklich alles haben – aber man kann das Risiko definitiv mindern, indem man übermäßig auf Ende-zu-Ende (E2E)-Tests setzt.
• Wie bei jeder Aufteilung einer benutzerorientierten Lösung entlang einer horizontalen Technologiegrenze besteht das Risiko, Wissenssilos zu schaffen und einen gewissen technischen Fokus auf Ende-zu-Ende-Benutzererfahrungen zu verlieren. Du musst dir dessen bewusst sein und das Risiko absichtlich mindern. Zu den effektivsten Maßnahmen gehören:
  • Richte Unterteams so aus, dass sie Funktionen statt Technologieschichten liefern.
  • Schule mobile Ingenieure, damit sie „Full Stack“ werden, d. h. in der Lage sind, über die Rust-Codebasis und die nativen Plattformen hinweg Fehler zu beheben, Support zu leisten und zu entwickeln.

Wie es mit der Engineering Transformation weitergeht

Von Anfang an war bei diesem Projekt klar, dass es um weit mehr als nur Proton Mail ging. Die erfolgreiche Anwendung dieses Technologie-Stacks auf Protons Flaggschiff-Anwendung war immer als erster Schritt einer längeren Reise gedacht – einer, die diesen Ansatz letztendlich auf den Rest unseres mobilen Ökosystems ausweiten würde.

Dieses Szenario entfaltet sich jetzt. Während ich diesen Artikel schreibe, werden unsere Konto- und Zahlungs-SDKs sowie die nächste Generation der mobilen Proton Calendar-Apps im Einklang mit dieser neuen technischen Richtung neu geschrieben.

Dies markiert den Beginn einer zweiten Welle der technischen Transformation – eine Evolution, die den Technologie-Blueprint um ein architektonisches Framework erweitert, das die Wiederverwendung von Komponenten erleichtert, nicht nur plattformübergreifend, sondern auch produktübergreifend. Obwohl dieser Übergang nicht über Nacht geschehen wird, ist er fundamental für den Aufbau des nahtlos integrierten, datenschutzorientierten Ökosystems, das unsere Kunden von Proton erwarten.

(1): Simon Lewis,“A strategy for application implementation on multiple platforms”, 2023.