Protons nya mobilappar för Mail: det finns mer än vad ögat ser

I september förra året lanserade vi en stor uppdatering av Proton Mail för iOS och Android.

På ytan levererar de nya apparna en modern design, bättre prestanda och offline-funktioner – men det finns mycket mer än vad ögat ser. Bakom kulisserna är apparna en fullständig omskrivning av Proton Mail på en ny teknikstack, ett projekt som internt går under namnet Engineering Transformation. Termen ny är avsiktlig, eftersom – såvitt vi vet – detta var första gången den valda tekniken användes i samband med en etablerad produktionsapplikation.

Den här artikeln syftar till att kasta ljus över den fascinerande resa som vårt team har gått igenom under skapandet av denna revolution, och att svara på några av de frågor som vårt community har ställt till oss längs vägen. Först och främst är logiken bakom detta behovet av att förändra status quo.

Hur allt började

Insikten att saker behövde förändras slog till en fredagskväll i oktober 2023. Den materialiserades med förvånande klarhet, men inte från ingenstans: det var kulmen på månader av försök att hitta en gemensam nämnare för de till synes orelaterade problemen som påverkade våra användares upplevelse med mobilprodukterna Mail och Calendar.

Med risk för att förenkla för mycket kan vi sammanfatta smärtpunkterna i tre områden:

• Kvalitet: Mail iOS och Mail Android, sedda isolerat, levde inte upp till förväntningarna när det gällde kvalitet och prestanda.
• Funktionsgap mellan iOS och Android: Vissa funktioner var endast tillgängliga på en plattform, utan klarhet om när den andra skulle komma ikapp.
• Ingenjörshastighet: Viktiga uppdateringar och efterlängtade funktioner levererades inte i tid över båda plattformarna.

Vissa av problemen sträckte sig bortom mobilen, och att besvara dem skulle kräva en utvikning från teknikdomänen till det fascinerande problemområdet för organisatorisk skalning, och särskilt snabbväxande tech-startups. Men bräckligheten i det mobila ekosystemet var i allra högsta grad rotad i teknik och arkitektur.

Skala mobilteknik

Att skala mobilteknik medför en unik uppsättning utmaningar som skiljer sig meningsfullt från att skala backend- och webbteam. Dessa skillnader härrör från plattformsfragmentering och de operativa verkligheterna i det mobila ekosystemet. Mobilteam behöver vanligtvis stödja flera plattformar över en mängd olika operativsystem och enheter (telefoner, surfplattor, ibland wearables). iOS och Android kommer med sina egna programmeringsspråk, ramverk och verktyg, vilket leder till stora mängder dubbelarbete: flera team, duplicerade kodbaser och ständiga avvägningar mellan plattformsspecifikt och produktrelaterat arbete. Att hålla produkterbjudandet synkroniserat kräver en enorm mängd samordning.

Vad som är en branschövergripande utmaning var särskilt akut för Proton. Funktionsappar som Mail och Calendar är i sig mer komplexa än de flesta mobilapplikationer på marknaden. När du lägger till det extra lagret av klientlogik som krävs för att hantera end-to-end-kryptering, slutar du med särskilt ”tjocka” klienter. Tidigare var Android-teamet upptaget med att skriva om Mail till bättre kvalitetsstandarder – en investering som tog större delen av 18 månader. iOS var också i stort behov av om-arkitektur, för att inte tala om Calendar. Kostnaden för duplicering åt upp alla våra ingenjörsresurser, och det blev tydligt att vi inte skulle lyckas genom att göra mer av samma sak.

Det bästa med att inse att du har fastnat är att det fungerar som en tvingande faktor för att tänka utanför begränsningarna i ditt nuvarande status quo. Vad skulle vi göra om vi kunde börja om på nytt, befriade från bördan av de val och åtaganden som ledde oss hit? När du tittar närmare på hur framgångsrika företag hanterade detta problem under det föregående decenniet inser du att de följde en av endast två möjliga strategier:

1. De kastade pengar på problemet, byggde allt större team då höga driftskostnader uppvägdes av en kombination av bottenlösa investeringar och/eller generösa avkastningar. Detta var inte ett alternativ för Protons VC-fria affärsmodell: vi kan inte konkurrera med utgifterna hos annonsbaserade, investerarstödda konkurrenter.
2. De omkonstruerade sina appar för att bli av med slöseriet, vilket innebär att bygga appar med (så mycket som möjligt) en delad kodbas.

Då alternativ 1 var uteslutet var vägen framåt utstakad.

Ett medel för ett mål: att välja rätt teknikstack

Nästa steg var att välja en teknikstack som faktiskt kunde göra jobbet.

Under de senaste 15 åren har plattformsoberoende mobilutveckling översvämmats med ”one-size-fits-all”-lösningar: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform och många andra. Var och en kom med samma löfte – att ersätta inbyggd utveckling helt och hållet. I praktiken misslyckades de flesta antingen helt eller lyckades bara inom strikt begränsade problemområden. Det finns ingen universell abstraktion som får plattformsskillnader att försvinna: alla som har levererat och underhållit stora mobilapplikationer vet detta. Det enda tillförlitliga sättet framåt är att arbeta baklänges från konkreta krav snarare än framåt från verktygstrender.

Vi översatte det slutmålet till en uppsättning icke-förhandlingsbara krav (1) som varje vald lösning var tvungen att uppfylla, och använde dem som vårt vägledande ramverk genom utvärderingsprocessen:

1. Kostnader och tidsramar: Stacken var tvungen att väsentligt minska kostnaden och tiden som krävs för att leverera, underhålla och utveckla Proton Mail över iOS och Android.
2. Användarupplevelse: Den var tvungen att bevara prestanda och interaktionskvalitet nära inbyggd (native) nivå – allt mindre var uteslutet.
3. Strategisk framtidssäkring: Lösningen var tvungen att vara långlivad. Vi var noga med att undvika tredjepartsramverk som skulle göra vår färdplan beroende av en annan leverantörs fortsatta support.

Spänningen mellan de två första begränsningarna är branschens version av den heliga graalen: ”En plattformsoberoende lösning som levererar prestandan och användarupplevelsen hos inbyggda applikationer.”

Vi var skeptiska från början till att React Native eller Flutter – de två dominerande plattformsoberoende ramverken vid den tiden – kunde nå denna nivå. Ändå validerade vi den skepticismen genom att bygga proof-of-concept-implementationer av Mails meddelandelistvy.

React Native avslöjade snabbt sina begränsningar. Att scrolla genom ett stort dataset gjorde kostnaden för dess tolkade exekveringsmodell smärtsamt uppenbar. Flutter presterade bättre, men användargränssnittet förblev synligt icke-inbyggt, särskilt på iOS. Ännu viktigare är att Flutter är ett proprietärt ramverk som kontrolleras av Google, som har en historia(nytt fönster) av att överge interna teknologier och nyligen hade sagt upp en stor del av Flutter-teamet. För en produkt med långsiktiga säkerhets- och tillförlitlighetsgarantier var den nivån av externt beroende oacceptabel.

Kotlin Multiplatform var nästa kandidat. Det är ett övertygande alternativ – särskilt för organisationer med djup Android-expertis – men det räckte i slutändan inte till för vårt användningsfall. Frånvaron av ett delat UI-lager, frågor kring mognad och den extra overhead som introducerades av dess exekveringsmodell vägde tyngre än fördelarna.

Vid denna punkt var slutsatsen tydlig och i linje med vår ursprungliga intuition: den enda arkitektur som konsekvent kommer nära det önskade resultatet är en avsiktligt blandad stack. Inbyggt UI på varje plattform – Jetpack Compose på Android, SwiftUI på iOS – uppbackat av ett delat affärslogiklager skrivet i ett högpresterande lågnivåspråk. Detta tillvägagångssätt har en meritlista: Dropbox använde berömt C++ för att dela affärslogik över mobila plattformar innan de övergav det 2019 på grund av språkets operativa och kognitiva kostnad.

I slutet av 2023 hade Rust tydligt framträtt som efterträdaren i linjen av systemprogrammeringsspråk.

Rust upptar samma prestandakuvert som C++, men utan många av dess historiska belastningar. Det ger starka minnessäkerhetsgarantier utan skräpinsamling (garbage collection), upprätthåller trådsäker samtidighet vid kompilering och stöds av ett stort, mycket kompetent ekosystem med öppen källkod. Lika viktigt är att Rust integreras rent med inbyggda mobilspråk – Swift och SwiftUI på iOS, Kotlin och Jetpack Compose på Android – vilket gör det till ett pragmatiskt val för att dela kärnlogik utan att kompromissa med UI-lagret.

Detta var inte ett riskfritt beslut. Vid den tiden fanns det få exempel på storskaliga, konsumentinriktade mobilapplikationer byggda på en Rust-centrerad arkitektur, och Rust-erfarenheten inom teamet var begränsad.

Men meningsfull innovation sker sällan i lågriskterritorium. Den verkliga utmaningen var inte Rust i sig, utan organisatorisk tröghet – att skifta från beprövade, konservativa tillvägagångssätt mot avsiktligt experimenterande, väglett av tydliga begränsningar och ingenjörsmässigt omdöme.

Det nya Proton Mail: resultat och lärdomar

Låt oss snabbspola till idag och se hur chansningen föll ut.

Diagrammet nedan representerar Mail-mobilens arkitektur. Rust-kärnan ansvarar för helheten av applikationens affärslogik. Vi pressade användningen av Rust bortom dess vanliga tillämpningar (nätverk, lagring, algoritmisk beräkning) hela vägen in i hanteringen av komplex navigeringslogik. Ett exempel är logiken som styr den oändliga scrollningen av meddelandelistan. Även om det är oortodox, visade sig detta vara nyckeln till att uppnå vårt mål att maximera kodåteranvändning. Som ett resultat delas nu nästan 80 % av kodbasen över iOS och Android.

Översattes detta till snabbare time-to-market med högre kvalitet? Även om det fortfarande är för tidigt för ett slutgiltigt omdöme har de tidiga tecknen varit mycket uppmuntrande:

• Under de två månaderna efter releasen lyckades teamet upprätthålla en veckovis takt av funktionsuppdateringar över båda plattformarna (totalt 12 funktionssläpp).
• Vi stängde funktionsgapen mellan plattformar och förde långlängtade funktioner till Android såsom snooze, kalender-RSVP och svep-för-nästa-meddelande.
• Även i detta tidiga skede har den nya kodbasen visat sig vara mer stabil än tidigare generationer på båda plattformarna: kraschfrekvensen för iOS är 0,05 % (ner från 0,12 %), medan Androids är tillbaka på en historisk baslinje (0,19 %). Detta är ett starkt stöd för Rusts körtidsstabilitet.

Support skalar också mer effektivt under detta tillvägagångssätt. Det är ofta snabbare att identifiera och lösa en enda, delad grundorsak än att jaga ytligt liknande problem som uppstår från något olika logikbrister utspridda över två oberoende kodbaser. Vi fann empirisk bekräftelse på vad som tidigare varit en arbetshypotes när vi fixade en klass av kategorisynkroniseringsproblem som påverkade logiken som ligger till grund för appens offline-funktioner: en grundorsak, en lösning – representerad i diagrammet ovan av ombaseringsmodulen som levererades med version 7.6.2.

Den andra sidan av myntet?

• Buggar och regressioner kommer sannolikt att ha en bredare inverkan och påverka användare på båda plattformarna. Du kan inte riktigt få allt – men du kan definitivt minska risken genom att överindexera på end-to-end-testning (E2E).
• Precis som med all uppdelning av en användarvänd lösning längs en horisontell teknikklyfta, finns det en risk att skapa kunskapssilor och förlora visst ingenjörsfokus på end-to-end-användarupplevelser. Du måste vara medveten om detta och avsiktligt minska risken. Bland de mest effektiva åtgärderna:
  • Rikta in underteam för att leverera funktioner snarare än tekniklager.
  • Utbilda mobilutvecklare till att bli ”fullstack”, dvs. kunna felsöka, ge support och utveckla över både Rust-kodbasen och de nativa plattformarna.

Vad som väntar härnäst för Engineering Transformation

Från första början av detta projekt var det tydligt att insatserna sträckte sig långt bortom enbart Proton Mail. Att framgångsrikt tillämpa denna teknikstack på Protons flaggskeppsapplikation var alltid avsett som det första steget i en längre resa – en som i slutändan skulle se detta tillvägagångssätt rullas ut över resten av vårt mobila ekosystem.

Det scenariot utspelar sig nu. När jag skriver denna artikel skrivs våra konto- och betalnings-SDK:er, liksom nästa generation av Proton Calendar-mobilappar, om i linje med denna nya tekniska riktning.

Detta markerar början på en andra våg av teknisk transformation – en evolution som utökar teknikritningen med ett arkitektoniskt ramverk utformat för att göra komponentåteranvändning enklare, inte bara över plattformar utan också över produkter. Även om denna övergång inte kommer att ske över en natt, är den grundläggande för att bygga det sömlöst integrerade, integritetsfokuserade ekosystem våra kunder förväntar sig att Proton ska vara.

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