Protons nye Mail-mobilapps: Der er mere, end øjet ser

I september sidste år lancerede vi en stor opdatering af Proton Mail til iOS og Android.

På overfladen leverer de nye apps et moderne design, bedre ydeevne og offline-funktioner—men der er meget mere, end øjet ser. Bag kulisserne er appsene en komplet omskrivning af Proton Mail på en ny teknologistak, et projekt, der går under det interne navn Engineering Transformation. Begrebet ny er bevidst, fordi — så vidt vi ved — dette har været første gang, den valgte teknologi er blevet brugt i sammenhæng med en etableret produktionsapplikation.

Denne artikel har til formål at kaste lys over den fascinerende rejse, vores team har været igennem i skabelsen af denne revolution, og at besvare nogle af de spørgsmål, vores fællesskab har stillet os undervejs. Først og fremmest er baggrunden behovet for at ændre status quo.

Hvordan det hele startede

Erkendelsen af, at tingene var nødt til at ændre sig, ramte en fredag aften i oktober 2023. Det materialiserede sig med overraskende klarhed, men ikke ud af det blå: Det var kulminationen på måneder brugt på at forsøge at finde en fællesnævner for de tilsyneladende urelaterede problemer, der påvirkede vores brugeres oplevelse med Mail- og Calendar-mobilprodukter.

Med risiko for at oversimplificere kan vi opsummere smertepunkterne i tre områder:

• Kvalitet: Mail iOS og Mail Android, set isoleret, levede ikke op til forventningerne med hensyn til kvalitet og ydeevne.
• Funktionsgab mellem iOS og Android: Nogle funktioner var kun tilgængelige på den ene platform, uden klarhed om, hvornår den anden ville indhente det.
• Udviklingshastighed: Nøgleopdateringer og længe ventede funktioner blev ikke leveret rettidigt på tværs af begge platforme.

Nogle af problemerne strakte sig ud over mobil, og at besvare dem ville kræve en afstikker fra teknologidomænet ind i det fascinerende problemrum med organisatorisk skalering, og især hurtigtvoksende tech-startups. Men skrøbeligheden i mobiløkosystemet var i høj grad rodfæstet i teknologi og arkitektur.

Skalering af mobiludvikling

Skalering af mobiludvikling kommer med et unikt sæt udfordringer, der er meningsfuldt forskellige fra skalering af backend- og webteams. Disse forskelle stammer fra platformsfragmentering og de operationelle realiteter i mobiløkosystemet. Mobilteams skal typisk understøtte flere platforme på tværs af en række operativsystemer og enheder (telefoner, tablets, nogle gange wearables). iOS og Android kommer med deres egne programmeringssprog, frameworks og værktøjer, hvilket fører til store mængder dobbeltarbejde: flere teams, duplikerede kodebaser og konstante afvejninger mellem platformsspecifikt og produktrelateret arbejde. At holde produktudbuddet synkroniseret kræver en enorm mængde koordinering.

Hvad der er en brancheomspændende udfordring, var særligt akut for Proton. Funktionalitetsapps såsom Mail og Calendar er i sagens natur mere komplekse end de fleste mobilapplikationer på markedet. Når man lægger det ekstra lag af klientlogik oveni, der kræves for at håndtere end-to-end-kryptering, ender man med særligt “tunge” klienter. Dengang havde Android-teamet travlt med at omskrive Mail til bedre kvalitetsstandarder—en investering, der tog størstedelen af 18 måneder. iOS havde også hårdt brug for omstrukturering, for ikke at nævne Calendar. Omkostningerne ved duplikering åd alle vores ingeniørressourcer, og det stod klart, at vi ikke ville lykkes ved at gøre mere af det samme.

Det bedste ved at erkende, at man sidder fast, er, at det fungerer som en drivkraft for at tænke uden for begrænsningerne af ens nuværende status quo. Hvad ville vi gøre, hvis vi kunne starte på ny, befriet fra byrden af de valg og forpligtelser, der førte os hertil? Når man kigger nærmere på, hvordan succesrige virksomheder håndterede dette problem i det foregående årti, indser man, at de fulgte en af kun to mulige strategier:

1. De kastede penge efter problemet, og opbyggede stadig større teams, da høje driftsomkostninger blev opvejet af en kombination af bundløse investeringer og/eller overdådige afkast. Dette var ikke en mulighed for Protons VC-fri forretningsmodel: Vi kan ikke konkurrere med forbruget hos reklamefinansierede, investorstøttede konkurrenter.
2. De omstrukturerede deres apps for at slippe af med spildet, hvilket betød at bygge apps ved hjælp af (så meget som muligt) en delt kodebase.

Da mulighed 1 var udelukket, var vejen frem fastlagt.

Et middel til målet: Valg af den rigtige teknologistak

Næste skridt var at vælge en teknologistak, der rent faktisk kunne klare opgaven.

I løbet af de sidste 15 år er mobiludvikling på tværs af platforme blevet oversvømmet med “one-size-fits-all”-løsninger: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform og mange andre. Hver ankom med det samme løfte—om at erstatte native udvikling fuldstændigt. I praksis fejlede de fleste enten fuldstændigt eller lykkedes kun inden for stramt begrænsede problemområder. Der findes ingen universel abstraktion, der får platformsforskelle til at forsvinde: Enhver, der har leveret og vedligeholdt store mobilapplikationer, ved dette. Den eneste pålidelige vej frem er at arbejde baglæns fra konkrete krav snarere end fremad fra værktøjstrends.

Vi oversatte det slutmål til et sæt ikke-forhandlingsbare krav (1), som enhver valgt løsning skulle opfylde, og brugte dem som vores styrende ramme gennem evalueringsprocessen:

1. Omkostninger og tidsrammer: Stakken skulle reducere omkostningerne og tiden, der kræves for at sende, vedligeholde og udvikle Proton Mail på tværs af iOS og Android, væsentligt.
2. Brugeroplevelse: Den skulle bevare næsten-native ydeevne og interaktionskvalitet—alt mindre var udelukket.
3. Strategisk fremtidssikring: Løsningen skulle være langtidsholdbar. Vi var bevidste om at undgå tredjepartsframeworks, der ville gøre vores køreplan afhængig af en anden leverandørs fortsatte support.

Spændingen mellem de to første begrænsninger er branchens version af den hellige gral: “En løsning på tværs af platforme, der leverer ydeevnen og brugeroplevelsen af native applikationer.”

Vi var skeptiske fra starten over for, om React Native eller Flutter—de to dominerende rammer på tværs af platforme på det tidspunkt—kunne nå denne barre. Alligevel validerede vi den skepsis ved at bygge proof-of-concept-implementeringer af Mails beskedlistevisning.

React Native afslørede hurtigt sine begrænsninger. At scrolle gennem et stort datasæt gjorde omkostningerne ved dens fortolkede udførelsesmodel smerteligt indlysende. Flutter præsterede bedre, men brugergrænsefladen forblev synligt ikke-native, især på iOS. Endnu vigtigere er Flutter et proprietært framework kontrolleret af Google, som har en historik(nyt vindue) med at opgive interne teknologier og for nylig havde afskediget en stor del af Flutter-teamet. For et produkt med langsigtede sikkerheds- og pålidelighedsgarantier var det niveau af ekstern afhængighed uacceptabelt.

Kotlin Multiplatform var den næste kandidat. Det er en overbevisende mulighed—især for organisationer med dyb Android-ekspertise—men det kom til kort for vores anvendelsestilfælde. Fraværet af et delt UI-lag, spørgsmål omkring modenhed og den ekstra overhead introduceret af dens udførelsesmodel opvejede fordelene.

På dette tidspunkt var konklusionen klar og i overensstemmelse med vores indledende intuition: Den eneste arkitektur, der konsekvent kommer tæt på det ønskede resultat, er en bevidst blandet stak. Native UI på hver platform – Jetpack Compose på Android, SwiftUI på iOS – bakket op af et delt forretningslogiklag skrevet i et højtydende sprog på lavt niveau. Denne tilgang har en historik: Dropbox brugte berømt C++ til at dele forretningslogik på tværs af mobile platforme, før de opgav det i 2019 på grund af de operationelle og kognitive omkostninger ved sproget.

Ved udgangen af 2023 var Rust tydeligt dukket op som efterfølgeren i rækken af systemprogrammeringssprog.

Rust befinder sig i samme ydeevne-konvolut som C++, men uden mange af dets historiske forpligtelser. Det giver stærke hukommelsessikkerhedsgarantier uden garbage collection, håndhæver trådsikker samtidighed ved kompileringstid og understøttes af et stort, meget kompetent open source-økosystem. Lige så vigtigt integreres Rust rent med native mobilsprog—Swift og SwiftUI på iOS, Kotlin og Jetpack Compose på Android—hvilket gør det til et pragmatisk valg til at dele kernelogik uden at gå på kompromis med UI-laget.

Dette var ikke en risikofri beslutning. På det tidspunkt var der få eksempler på store, forbrugerrettede mobilapplikationer bygget på en Rust-centreret arkitektur, og Rust-erfaringen i teamet var begrænset.

Men meningsfuld innovation sker sjældent i lavrisikoterritorium. Den virkelige udfordring var ikke Rust selv, men organisatorisk inerti—at skifte fra gennemprøvede, konservative tilgange til bevidst eksperimentering, styret af klare begrænsninger og ingeniørmæssig dømmekraft.

Det nye Proton Mail: Resultat og læring

Lad os spole frem til i dag og se, hvordan satsningen faldt ud.

Diagrammet nedenfor repræsenterer Mail-mobilarkitekturen. Rust-kernen er ansvarlig for hele applikationens forretningslogik. Vi skubbede brugen af Rust ud over dets sædvanlige applikationer (netværk, lagring, algoritmisk beregning) helt ind i håndteringen af kompleks navigationslogik. Et eksempel er logikken, der styrer den endeløse scrolling af beskedlisten. Selvom det var uortodokst, viste dette sig at være nøglen til at nå vores mål om at maksimere genbrug af kode. Som et resultat deles næsten 80 % af kodebasen nu på tværs af iOS og Android.

Omsatte dette sig til hurtigere time-to-market af højere kvalitet? Mens det stadig er for tidligt til en endelig dom, har de tidlige tegn været meget opmuntrende:

• I de to måneder efter udgivelsen lykkedes det teamet at opretholde en ugentlig kadence af funktionsopdateringer på tværs af begge platforme (i alt 12 funktionsudgivelser).
• Vi lukkede funktionskløfterne mellem platforme og bragte længe ventede funktioner til Android såsom snooze, kalender-RSVP og swipe-to-next-message.
• Selv på dette tidlige stadie har den nye kodebase vist sig mere stabil end tidligere generationer på begge platforme: iOS-nedbrudsraten er 0,05 % (ned fra 0,12 %), mens Androids er tilbage på et historisk udgangspunkt (0,19 %). Dette er en stærk godkendelse af Rusts runtime-stabilitet.

Support skalerer også mere effektivt under denne tilgang. Det er ofte hurtigere at identificere og løse en enkelt, delt grundårsag end at jagte overfladisk lignende problemer, der opstår fra lidt forskellige logiske fejl spredt over to uafhængige kodebaser. Vi fandt empirisk bekræftelse på, hvad der tidligere havde været en arbejdshypotese, mens vi fiksede en klasse af kategorisynkroniseringsproblemer, der påvirkede logikken, som understøtter appens offline-kapaciteter: Én grundårsag, én løsning—repræsenteret i diagrammet ovenfor ved Rebasing-modulet, der blev leveret med version 7.6.2.

Den anden side af medaljen?

• Fejl og regressioner vil sandsynligvis have en bredere indvirkning og påvirke brugere på begge platforme. Man kan ikke rigtig få det hele—men man kan helt sikkert mindske risikoen ved at overindeksere på end-to-end (E2E) test.
• Som med enhver opdeling af en brugerrettet løsning langs en horisontal teknologisk skillelinje, er der en risiko for at skabe vidensiloer og miste noget ingeniørmæssigt fokus på end-to-end brugeroplevelser. Du skal være opmærksom på dette og bevidst mindske risikoen. Blandt de mest effektive foranstaltninger:
  • Juster underteams til at levere funktioner frem for teknologilag.
  • Uddan mobilingeniører til at blive “full stack”, dvs. i stand til at debugge, supportere og udvikle på tværs af både Rust-kodebasen og de native platforme.

Hvad er næste skridt for Engineering Transformation

Allerede fra starten af dette projekt stod det klart, at indsatsen strakte sig langt ud over Proton Mail alene. Succesfuld anvendelse af denne teknologistak på Protons flagskibsapplikation var altid tiltænkt som det første skridt på en længere rejse—en rejse, der i sidste ende ville se denne tilgang rullet ud over resten af vores mobile økosystem.

Det scenarie udfolder sig nu. Mens jeg skriver denne artikel, bliver vores Account og Payment SDK’er, såvel som den næste generation af Proton Calendar-mobilapps, omskrevet i overensstemmelse med denne nye tekniske retning.

Dette markerer begyndelsen på en anden bølge af ingeniørmæssig transformation—en udvikling, der udvider teknologitegningen med en arkitektonisk ramme designet til at gøre genbrug af komponenter nemmere, ikke kun på tværs af platforme, men også på tværs af produkter. Selvom denne overgang ikke sker natten over, er den fundamental for at opbygge det problemfrit integrerede, privatlivs-første økosystem, vores kunder forventer, at Proton skal være.

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