De nieuwe mobiele apps van Proton Mail: er is meer dan het oog ziet

In september vorig jaar lanceerden we een grote update van Proton Mail voor iOS en Android.

Op het eerste gezicht leveren de nieuwe apps een modern ontwerp, betere prestaties en offline mogelijkheden — maar er is veel meer dan het oog ziet. Achter de schermen zijn de apps een volledige herschrijving van Proton Mail op een nieuwe technologiestack, een project dat intern de naam Engineering Transformation draagt. De term nieuw is bewust gekozen, omdat — voor zover wij weten — dit de eerste keer is dat de gekozen technologie is gebruikt in de context van een gevestigde productietoepassing.

Dit artikel heeft als doel licht te werpen op de fascinerende reis die ons team heeft afgelegd bij het maken van deze revolutie, en om enkele vragen te beantwoorden die onze gemeenschap ons onderweg heeft gesteld. Eerst en vooral is de rationale erachter de noodzaak om de status quo te veranderen.

Hoe het allemaal begon

Het besef dat er dingen moesten veranderen, kwam op een vrijdagavond in oktober 2023. Het materialiseerde zich met verrassende helderheid, maar niet uit het niets: het was het hoogtepunt van maanden proberen een gemene deler te vinden voor de ogenschijnlijk ongerelateerde problemen die de ervaring van onze gebruikers met mobiele producten voor Mail en Agenda beïnvloedden.

Met het risico te simplificeren, kunnen we de pijnpunten samenvatten in drie gebieden:

• Kwaliteit: Mail iOS en Mail Android voldeden, afzonderlijk genomen, niet aan de verwachtingen op het gebied van kwaliteit en prestaties.
• Functiekloof tussen iOS en Android: Sommige functies waren alleen beschikbaar op één platform, zonder duidelijkheid over wanneer het andere zou bijbenen.
• Engineering-snelheid: Belangrijke updates en langverwachte functies werden niet tijdig op beide platforms geleverd.

Sommige problemen reikten verder dan mobiel, en om die te beantwoorden zou een uitweiding nodig zijn van het technologiedomein naar de fascinerende problematiek van organisatorische schaalvergroting, en in het bijzonder snelgroeiende tech-startups. Maar de kwetsbaarheid van het mobiele ecosysteem was heel erg geworteld in technologie en architectuur.

Schalen van Mobile Engineering

Het schalen van mobile engineering brengt een unieke set uitdagingen met zich mee die zinvol verschillen van het schalen van backend- en webteams. Deze verschillen komen voort uit platformfragmentatie en de operationele realiteit van het mobiele ecosysteem. Mobiele teams moeten doorgaans meerdere platforms ondersteunen op verschillende besturingssystemen en apparaten (telefoons, tablets, soms wearables). iOS en Android hebben hun eigen programmeertalen, frameworks en tools, wat leidt tot grote hoeveelheden dubbel werk: meerdere teams, dubbele codebases en constante afwegingen tussen platformspecifiek en productgerelateerd werk. Het synchroon houden van het productaanbod vereist een enorme hoeveelheid coördinatie.

Wat een sectorbrede uitdaging is, was bijzonder acuut voor Proton. Functionaliteitstoepassingen zoals Mail en Agenda zijn inherent complexer dan de meeste mobiele toepassingen op de markt. Wanneer u daar de extra laag clientlogica aan toevoegt die nodig is om end-to-end versleuteling te verwerken, krijgt u bijzonder “dikke” clients. Vroeger was het Android-team druk bezig met het herschrijven van Mail naar betere kwaliteitsnormen — een investering die het grootste deel van 18 maanden in beslag nam. iOS had ook dringend een nieuwe architectuur nodig, om nog maar te zwijgen van Agenda. De kosten van duplicatie vraten al onze engineeringmiddelen op, en het werd duidelijk dat we niet zouden slagen door meer van hetzelfde te doen.

Het beste aan erkennen dat u vastzit, is dat het fungeert als een dwingende factor om buiten de beperkingen van uw huidige status quo te denken. Wat zouden we doen als we opnieuw konden beginnen, bevrijd van de last van de keuzes en verplichtingen die ons hier hebben gebracht? Als u nader bekijkt hoe succesvolle bedrijven dit probleem in het afgelopen decennium hebben aangepakt, realiseert u zich dat ze een van slechts twee mogelijke strategieën volgden:

1. Ze gooiden geld tegen het probleem aan, en bouwden steeds grotere teams omdat hoge operationele kosten werden gecompenseerd door een combinatie van bodemloze investeringen en/of royale rendementen. Dit was geen optie voor Proton’s VC-vrije bedrijfsmodel: we kunnen niet concurreren met de uitgaven van op advertenties gebaseerde, door investeerders gesteunde concurrenten.
2. Ze hebben hun apps opnieuw ontworpen om van de verspilling af te komen, wat betekent dat ze apps hebben gebouwd met (zoveel mogelijk) een gedeelde codebase.

Aangezien optie 1 geen optie was, lag de weg vooruit vast.

Een middel tot een doel: de juiste tech-stack kiezen

De volgende stap was het kiezen van een tech-stack die de klus daadwerkelijk kon klaren.

De afgelopen 15 jaar is platformonafhankelijke mobiele ontwikkeling overspoeld met “one-size-fits-all”-oplossingen: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform en vele andere. Elk kwam met dezelfde belofte — om native ontwikkeling direct te vervangen. In de praktijk faalden de meeste direct of slaagden ze alleen binnen strikt beperkte probleemruimten. Er is geen universele abstractie die platformverschillen doet verdwijnen: iedereen die grote mobiele toepassingen heeft verzonden en onderhouden, weet dit. De enige betrouwbare weg vooruit is om terug te werken vanuit concrete vereisten in plaats van vooruit vanuit toolingtrends.

We vertaalden dat einddoel in een reeks ononderhandelbare vereisten (1) waaraan elke gekozen oplossing moest voldoen, en gebruikten ze als ons leidend kader gedurende het evaluatieproces:

1. Kosten en tijdschema’s: De stack moest de kosten en tijd die nodig waren om Proton Mail op iOS en Android te verzenden, te onderhouden en te ontwikkelen materieel verminderen.
2. Gebruikerservaring: Het moest bijna-native prestaties en interactiekwaliteit behouden — alles minder was geen optie.
3. Strategische toekomstbestendigheid: De oplossing moest een lange levensduur hebben. We waren opzettelijk in het vermijden van frameworks van derden die onze roadmap afhankelijk zouden maken van de voortdurende ondersteuning van een andere leverancier.

De spanning tussen de eerste twee beperkingen is de versie van de heilige graal in de sector: “Een platformonafhankelijke oplossing die de prestaties en gebruikerservaring van native toepassingen levert.”

We waren vanaf het begin sceptisch dat React Native of Flutter — destijds de twee dominante platformonafhankelijke frameworks — deze lat konden halen. Toch hebben we die scepsis gevalideerd door proof-of-concept-implementaties van de berichtenlijstweergave van Mail te bouwen.

React Native onthulde snel zijn beperkingen. Scrollen door een grote dataset maakte de kosten van zijn geïnterpreteerde uitvoeringsmodel pijnlijk duidelijk. Flutter presteerde beter, maar de UI bleef zichtbaar niet-native, vooral op iOS. Belangrijker nog is dat Flutter een eigen framework is dat wordt beheerd door Google, dat een geschiedenis(nieuw venster) heeft van het verlaten van interne technologieën en onlangs een groot deel van het Flutter-team heeft ontslagen. Voor een product met garanties voor beveiliging en betrouwbaarheid op lange termijn was dat niveau van externe afhankelijkheid onaanvaardbaar.

Kotlin Multiplatform was de volgende kandidaat. Het is een aantrekkelijke optie — met name voor organisaties met diepgaande Android-expertise — maar het schoot uiteindelijk tekort voor ons gebruiksscenario. De afwezigheid van een gedeelde UI-laag, vragen over volwassenheid en de extra overhead die door het uitvoeringsmodel werd geïntroduceerd, wogen zwaarder dan de voordelen.

Op dit punt was de conclusie duidelijk en in lijn met onze initiële intuïtie: de enige architectuur die consequent dicht in de buurt komt van het gewenste resultaat is een bewust gemengde stack. Native UI op elk platform – Jetpack Compose op Android, SwiftUI op iOS – ondersteund door een gedeelde bedrijfslogica-laag geschreven in een hoogwaardige taal op laag niveau. Deze aanpak heeft een staat van dienst: Dropbox gebruikte beroemd C++ om bedrijfslogica te delen over mobiele platforms voordat ze het in 2019 verlieten vanwege de operationele en cognitieve kosten van de taal.

Tegen het einde van 2023 was Rust duidelijk naar voren gekomen als de opvolger in de lijn van systeemprogrammeertalen.

Rust bevindt zich in hetzelfde prestatiebereik als C++, maar zonder veel van zijn historische nadelen. Het biedt sterke geheugenveiligheidsgaranties zonder garbage collection, dwingt thread-safe gelijktijdigheid af tijdens compileertijd en wordt ondersteund door een groot, zeer competent open-source ecosysteem. Net zo belangrijk is dat Rust naadloos integreert met native mobiele talen — Swift en SwiftUI op iOS, Kotlin en Jetpack Compose op Android — waardoor het een pragmatische keuze is voor het delen van kernlogica zonder de UI-laag in gevaar te brengen.

Dit was geen risicovrije beslissing. Destijds waren er weinig voorbeelden van grootschalige, consumentgerichte mobiele toepassingen die op een Rust-centrische architectuur waren gebouwd, en de Rust-ervaring binnen het team was beperkt.

Maar zinvolle innovatie gebeurt zelden in een gebied met een laag risico. De echte uitdaging was niet Rust zelf, maar organisatorische traagheid — verschuiven van bewezen, conservatieve benaderingen naar bewust experimenteren, geleid door duidelijke beperkingen en technisch oordeel.

De nieuwe Proton Mail: resultaat en lessen

Laten we vooruitspoelen naar vandaag en zien hoe de gok heeft uitgepakt.

Het onderstaande diagram vertegenwoordigt de architectuur van Mail mobiel. De Rust-kern is verantwoordelijk voor de volledige bedrijfslogica van de toepassing. We hebben het gebruik van Rust verder geduwd dan zijn gebruikelijke toepassingen (netwerken, opslag, algoritmische berekening) tot in de afhandeling van complexe navigatielogica. Een voorbeeld hiervan is de logica die het oneindig scrollen van de berichtenlijst regelt. Hoewel onorthodox, bleek dit essentieel om ons doel te bereiken om hergebruik van code te maximaliseren. Als gevolg hiervan wordt bijna 80% van de codebase nu gedeeld tussen iOS en Android.

Vertaalde dit zich in een snellere, hoogwaardigere time-to-market? Hoewel het nog te vroeg is voor een definitief oordeel, zijn de vroege signalen zeer bemoedigend:

• In de twee maanden na de release slaagde het team erin een wekelijks ritme van functie-updates op beide platforms te handhaven (in totaal 12 functiereleases).
• We hebben de functiekloven tussen platforms gedicht door langverwachte functies naar Android te brengen, zoals snooze, agenda-RSVP en swipe-to-next-message.
• Zelfs in dit vroege stadium is de nieuwe codebase stabieler gebleken dan voorgaande generaties op beide platforms: het crashpercentage op iOS is 0,05% (gedaald van 0,12%), terwijl dat van Android terug is op een historische basislijn (0,19%). Dit is een sterke onderschrijving van de runtime-stabiliteit van Rust.

Ondersteuning schaalt ook effectiever onder deze aanpak. Het is vaak sneller om een enkele, gedeelde hoofdoorzaak te identificeren en op te lossen dan om oppervlakkig vergelijkbare problemen na te jagen die voortkomen uit iets andere logische fouten verspreid over twee onafhankelijke codebases. We vonden empirische bevestiging van wat voorheen een werkhypothese was tijdens het oplossen van een klasse categoriesynchronisatieproblemen die de logica beïnvloedden die de offline mogelijkheden van de app ondersteunt: één hoofdoorzaak, één oplossing — weergegeven in het bovenstaande diagram door de Rebasing-module die is verzonden met versie 7.6.2.

De andere kant van de medaille?

• Bugs en regressies hebben waarschijnlijk een bredere impact en beïnvloeden gebruikers op beide platforms. U kunt niet echt alles hebben — maar u kunt het risico zeker beperken door te over-indexeren op end-to-end (E2E) testen.
• Zoals bij elke opsplitsing van een gebruikersgerichte oplossing langs een horizontale technologiekloof, bestaat het risico dat kennissilo’s worden gecreëerd en enige technische focus op end-to-end gebruikerservaringen verloren gaat. U moet zich hiervan bewust zijn en het risico opzettelijk beperken. Onder de meest effectieve maatregelen:
  • Stem subteams op elkaar af om functies te leveren in plaats van technologielagen.
  • Train mobiele ingenieurs om “full stack” te worden, d.w.z. in staat om te debuggen, te ondersteunen en te engineeren over zowel de Rust-codebase als de native platforms.

Wat volgt voor Engineering Transformation

Vanaf het allereerste begin van dit project was het duidelijk dat de belangen veel verder reikten dan alleen Proton Mail. Het succesvol toepassen van deze technologiestack op de vlaggenschiptoepassing van Proton was altijd bedoeld als de eerste stap in een langere reis — een die uiteindelijk deze aanpak uitgerold zou zien over de rest van ons mobiele ecosysteem.

Dat scenario ontvouwt zich nu. Terwijl ik dit artikel schrijf, worden onze SDK’s voor account en betaling, evenals de volgende generatie mobiele apps van Proton Calendar, herschreven in overeenstemming met deze nieuwe technische richting.

Dit markeert het begin van een tweede golf van technische transformatie — een evolutie die de blauwdruk van de technologie uitbreidt met een architecturaal kader dat is ontworpen om hergebruik van componenten gemakkelijker te maken, niet alleen over platforms heen, maar ook over producten heen. Hoewel deze overgang niet van de ene op de andere dag zal plaatsvinden, is het fundamenteel voor het bouwen van het naadloos geïntegreerde, privacy-first ecosysteem dat onze klanten van Proton verwachten.

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