Protons nye Mail-mobilapper: Det er mer enn øyet kan se

I september i fjor lanserte vi en stor oppdatering av Proton Mail for iOS og Android.

På overflaten leverer de nye appene et moderne design, bedre ytelse og frakoblede funksjoner – men det er mye mer enn øyet kan se. Bak kulissene er appene en fullstendig omskriving av Proton Mail på en ny teknologistakk, et prosjekt som går under det interne navnet Engineering Transformation. Begrepet ny er bevisst, fordi – etter vår beste viten – har dette vært første gang den valgte teknologien har blitt brukt i sammenheng med en etablert produksjonsapplikasjon.

Denne artikkelen tar sikte på å kaste lys over den fascinerende reisen teamet vårt har vært gjennom i skapelsen av denne revolusjonen, og å svare på noen av spørsmålene fellesskapet vårt har stilt oss underveis. Først og fremst er begrunnelsen bak behovet for å endre status quo.

Hvordan det hele startet

Erkjennelsen av at ting måtte endres, slo ned en fredagskveld i oktober 2023. Den materialiserte seg med overraskende klarhet, men ikke ut av det blå: Den var kulminasjonen av måneder brukt på å prøve å finne en fellesnevner for de tilsynelatende urelaterte problemene som påvirket brukernes opplevelse av mobilproduktene Mail og Kalender.

Med fare for å overforenkle, kan vi oppsummere smertepunktene i tre områder:

• Kvalitet: Mail iOS og Mail Android, tatt isolert sett, levde ikke opp til forventningene når det gjaldt kvalitet og ytelse.
• Funksjonsgap mellom iOS og Android: Noen funksjoner var bare tilgjengelige på én plattform, uten klarhet om når den andre ville ta igjen.
• Utviklingshastighet: Viktige oppdateringer og etterlengtede funksjoner ble ikke levert i tide på tvers av begge plattformer.

Noen av problemene strakte seg utover mobil, og å svare på disse ville kreve en digresjon fra teknologidomenet og inn i det fascinerende problemområdet med organisatorisk skalering, og spesielt hurtigvoksende tek-oppstartsselskaper. Men skjørheten i det mobile økosystemet var i stor grad forankret i teknologi og arkitektur.

Skalering av mobilutvikling

Å skalere mobilutvikling kommer med et unikt sett med utfordringer som er betydelig annerledes enn å skalere backend- og nett-team. Disse forskjellene stammer fra plattformfragmentering og de operasjonelle realitetene i det mobile økosystemet. Mobilteam må vanligvis støtte flere plattformer på tvers av en rekke operativsystemer og enheter (telefoner, nettbrett, noen ganger kroppsbårne enheter). iOS og Android kommer med sine egne programmeringsspråk, rammeverk og verktøy, noe som fører til store mengder duplisert innsats: flere team, dupliserte kodebaser og konstante kompromisser mellom plattformspesifikt og produktrelatert arbeid. Å holde produkttilbudet synkronisert krever en enorm mengde koordinering.

Det som er en bransjeomfattende utfordring, var spesielt akutt for Proton. Funksjonalitetsapper som Mail og Kalender er i seg selv mer komplekse enn de fleste mobilapplikasjoner på markedet. Når du på toppen legger til det ekstra laget med klientlogikk som kreves for å håndtere ende-til-ende-kryptering, ender du opp med spesielt «tykke» klienter. I sin tid var Android-teamet opptatt med å skrive om Mail til bedre kvalitetsstandarder – en investering som tok mesteparten av 18 måneder. iOS hadde også et stort behov for omstrukturering, for ikke å snakke om Kalender. Kostnaden for duplisering spiste av alle våre utviklingsressurser, og det ble klart at vi ikke kom til å lykkes ved å gjøre mer av det samme.

Det beste med å innse at du sitter fast, er at det fungerer som en tvingende faktor til å tenke utenfor begrensningene til din nåværende status quo. Hva ville vi gjort hvis vi kunne starte på nytt, frigjort fra byrden av valgene og forpliktelsene som førte oss hit? Når du tar en nærmere titt på hvordan vellykkede selskaper håndterte dette problemet i det forrige tiåret, innser du at de fulgte én av bare to mulige strategier:

1. De kastet penger på problemet, og bygde stadig større team ettersom høye driftskostnader ble oppveid av en kombinasjon av bunnløse investeringer og/eller overdådig avkastning. Dette var ikke et alternativ for Protons VC-frie forretningsmodell: Vi kan ikke konkurrere med pengebruken til annonsebaserte, investorstøttede konkurrenter.
2. De ombygde appene sine for å kvitte seg med svinn, noe som betyr å bygge apper ved hjelp av (så mye som mulig) en delt kodebase.

Med alternativ 1 som en umulighet, var banen videre satt.

Et middel til et mål: å velge riktig teknologistakk

Neste trinn var å velge en teknologistakk som faktisk kunne gjøre jobben.

I løpet av de siste 15 årene har mobilutvikling på tvers av plattformer blitt oversvømmet med «one-size-fits-all»-løsninger: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform og mange andre. Hver kom med det samme løftet – om å erstatte opprinnelig utvikling direkte. I praksis har de fleste enten mislyktes fullstendig eller bare lyktes innenfor stramt begrensede problemområder. Det finnes ingen universell abstraksjon som får plattformforskjeller til å forsvinne: Alle som har levert og vedlikeholdt store mobilapplikasjoner vet dette. Den eneste pålitelige veien fremover er å jobbe bakover fra konkrete krav fremfor fremover fra verktøytrender.

Vi oversatte det sluttmålet til et sett med ufravikelige krav (1) som enhver valgt løsning måtte tilfredsstille, og brukte dem som vårt veiledende rammeverk gjennom hele evalueringsprosessen:

1. Kostnader og tidsrammer: Stakken måtte redusere kostnadene og tiden som kreves for å levere, vedlikeholde og utvikle Proton Mail på tvers av iOS og Android vesentlig.
2. Brukeropplevelse: Den måtte bevare en ytelse og interaksjonskvalitet som var tilnærmet opprinnelig – alt annet var uaktuelt.
3. Strategisk fremtidssikring: Løsningen måtte være langvarig. Vi var bevisste på å unngå tredjeparts rammeverk som ville gjøre veikartet vårt avhengig av en annen leverandørs fortsatte støtte.

Spenningen mellom de to første begrensningene er bransjens versjon av den hellige gral: «En kryssplattformløsning som leverer ytelsen og brukeropplevelsen til opprinnelige applikasjoner.»

Vi var skeptiske helt fra starten til at React Native eller Flutter – de to dominerende kryssplattformrammeverkene på den tiden – kunne nå dette nivået. Likevel validerte vi denne skepsisen ved å bygge konseptbevis-implementeringer av Mails meldingslistevisning.

React Native avslørte raskt sine begrensninger. Å rulle gjennom et stort datasett gjorde kostnaden av dens tolkede utførelsesmodell smertelig åpenbar. Flutter presterte bedre, men brukergrensesnittet forble synlig uoriginalt (non-native), spesielt på iOS. Enda viktigere er det at Flutter er et proprietært rammeverk kontrollert av Google, som har en historikk(nytt vindu) for å forlate interne teknologier og nylig hadde sagt opp en stor del av Flutter-teamet. For et produkt med langsiktige sikkerhets- og pålitelighetsgarantier, var det nivået av ekstern avhengighet uakseptabelt.

Kotlin Multiplatform var neste kandidat. Det er et overbevisende alternativ – spesielt for organisasjoner med dyp Android-ekspertise – men det kom til kort for vårt bruksområde. Fraværet av et delt brukergrensesnittlag, spørsmål rundt modenhet og den ekstra merbelastningen introdusert av utførelsesmodellen, oppveide fordelene.

På dette tidspunktet var konklusjonen klar og på linje med vår opprinnelige intuisjon: den eneste arkitekturen som konsekvent kommer nær det ønskede resultatet, er en bevisst blandet stakk. Opprinnelig brukergrensesnitt på hver plattform – Jetpack Compose på Android, SwiftUI på iOS – støttet av et delt forretningslogikklag skrevet i et høyytelses, lavnivåspråk. Denne tilnærmingen har en merittliste: Dropbox brukte kjent C++ for å dele forretningslogikk på tvers av mobile plattformer før de forlot det i 2019 på grunn av de operasjonelle og kognitive kostnadene ved språket.

Innen utgangen av 2023 hadde Rust tydelig fremstått som etterfølgeren i rekken av systemprogrammeringsspråk.

Rust befinner seg i samme ytelsesområde som C++, men uten mange av dets historiske svakheter. Det gir sterke minnesikkerhetsgarantier uten søppelinnsamling, håndhever trådsikker samtidighet ved kompilering, og har støtte fra et stort, svært kompetent åpen kildekode-økosystem. Like viktig er det at Rust integreres rent med opprinnelige mobilspråk – Swift og SwiftUI på iOS, Kotlin og Jetpack Compose på Android – noe som gjør det til et pragmatisk valg for å dele kjernelogikk uten å kompromittere brukergrensesnittslaget.

Dette var ikke en risikofri beslutning. På den tiden var det få eksempler på store, forbrukerrettede mobilapplikasjoner bygget på en Rust-sentrisk arkitektur, og Rust-erfaringen i teamet var begrenset.

Men meningsfull innovasjon skjer sjelden i lavrisikoterritorium. Den virkelige utfordringen var ikke Rust i seg selv, men organisatorisk treghet – å skifte fra utprøvde, konservative tilnærminger til bevisst eksperimentering, styrt av tydelige begrensninger og teknisk skjønn.

Nye Proton Mail: utfall og lærdommer

La oss spole frem til i dag og se hvordan sjansespillet spilte seg ut.

Diagrammet nedenfor representerer arkitekturen til Mails mobilapp. Rust-kjernen er ansvarlig for hele applikasjonens forretningslogikk. Vi presset bruken av Rust utover de vanlige applikasjonene (nettverk, lagring, algoritmisk beregning) helt inn i håndteringen av kompleks navigasjonslogikk. Et godt eksempel er logikken som styrer den uendelige rullingen av meldingslisten. Selv om det er uortodokst, viste dette seg å være nøkkelen til å oppnå målet vårt om å maksimere gjenbruk av kode. Som et resultat er nesten 80 % av kodebasen nå delt på tvers av iOS og Android.

Oversatte dette seg til raskere time-to-market av høyere kvalitet? Selv om det fortsatt er for tidlig for en endelig dom, har de tidlige tegnene vært veldig oppmuntrende:

• I de to månedene etter utgivelsen klarte teamet å opprettholde en ukentlig takt med funksjonsoppdateringer på tvers av begge plattformer (totalt 12 funksjonsutgivelser).
• Vi lukket funksjonsgapene mellom plattformer, og brakte etterlengtede funksjoner til Android som å slumre, kalender-RSVP og sveip-til-neste-melding.
• Selv på dette tidlige stadiet har den nye kodebasen vist seg å være mer stabil enn tidligere generasjoner på begge plattformer: iOS-krasjfrekvensen er 0,05 % (ned fra 0,12 %), mens Androids er tilbake til en historisk grunnlinje (0,19 %). Dette er en sterk anerkjennelse av Rusts kjøretidsstabilitet.

Støtte skalerer også mer effektivt med denne tilnærmingen. Det er ofte raskere å identifisere og løse en enkelt, delt rotårsak enn å jakte på overfladisk lignende problemer som oppstår fra litt forskjellige logikkfeil spredt over to uavhengige kodebaser. Vi fant empirisk bekreftelse på det som tidligere hadde vært en arbeidshypotese mens vi fikset en klasse med kategorisynkroniseringsproblemer som påvirket logikken som underbygger appens frakoblede evner: én rotårsak, én løsning – representert i diagrammet ovenfor ved Rebasing-modulen levert med versjon 7.6.2.

Den andre siden av mynten?

• Feil og regresjoner vil sannsynligvis ha en bredere innvirkning og påvirke brukere på begge plattformer. Du kan egentlig ikke få i pose og sekk – men du kan definitivt redusere risikoen ved å overindeksere på ende-til-ende-testing (E2E).
• Som med all oppdeling av en brukerrettet løsning langs et horisontalt teknologiskille, er det en risiko for å skape kunnskapssiloer og miste noe av det tekniske fokuset på ende-til-ende-brukeropplevelser. Du må være oppmerksom på dette og bevisst redusere risikoen. Blant de mest effektive tiltakene:
  • Samkjør underteam for å levere funksjoner i stedet for teknologilag.
  • Lær opp mobilingeniører til å bli «full stack», dvs. i stand til å feilsøke, støtte og konstruere på tvers av både Rust-kodebasen og de opprinnelige plattformene.

Hva er neste steg for Engineering Transformation

Helt fra starten av dette prosjektet var det klart at innsatsen strakk seg langt utover bare Proton Mail. Å lykkes med å bruke denne teknologistakken på Protons flaggskipapplikasjon var alltid ment som det første skrittet på en lengre reise – en som til slutt ville se denne tilnærmingen rullet ut på tvers av resten av mobiløkosystemet vårt.

Dette scenariet utspiller seg nå. Mens jeg skriver denne artikkelen, blir konto- og betalings-SDK-ene våre, samt neste generasjon Proton Calendar-mobilapper, skrevet om i tråd med denne nye tekniske retningen.

Dette markerer begynnelsen på en andre bølge av teknisk transformasjon – en utvikling som utvider teknologitegningen med et arkitektonisk rammeverk designet for å gjøre gjenbruk av komponenter enklere, ikke bare på tvers av plattformer, men også på tvers av produkter. Selv om denne overgangen ikke vil skje over natten, er den fundamental for å bygge det sømløst integrerte økosystemet med personvern i høysetet som kundene våre forventer at Proton skal være.

(1): Simon Lewis, «En strategi for applikasjonsimplementering på flere plattformer», 2023.