Noile aplicații mobile Proton Mail: mai mult decât se vede

În septembrie anul trecut, am lansat o actualizare majoră a Proton Mail pentru iOS și Android.

La suprafață, noile aplicații oferă un design modern, performanță mai bună și capabilități deconectate — dar există mult mai mult decât se vede. În culise, aplicațiile sunt o rescriere completă a Proton Mail pe o stivă tehnologică nouă, un proiect care poartă numele intern de Transformare Inginierească. Termenul nou este deliberat, deoarece — din câte știm — a fost prima dată când tehnologia aleasă a fost utilizată în contextul unei aplicații de producție stabilite.

Acest articol își propune să facă lumină asupra călătoriei fascinante prin care a trecut echipa noastră în realizarea acestei revoluții și să răspundă la unele dintre întrebările pe care comunitatea noastră ni le-a pus pe parcurs. În primul rând, raționamentul din spate este necesitatea de a schimba status quo-ul.

Cum a început totul

Conștientizarea faptului că lucrurile trebuiau să se schimbe a venit într-o vineri seara din octombrie 2023. S-a materializat cu o claritate surprinzătoare, dar nu din senin: a fost punctul culminant al lunilor petrecute încercând să găsim un numitor comun pentru problemele aparent nelegate care afectau experiența utilizatorilor noștri cu produsele mobile Mail și Calendar.

Cu riscul de a simplifica excesiv, putem rezuma punctele dureroase în trei domenii:

• Calitate: Mail iOS și Mail Android, luate izolat, nu au îndeplinit așteptările în ceea ce privește calitatea și performanța.
• Decalaj de caracteristici între iOS și Android: Unele caracteristici erau disponibile doar pe o platformă, fără claritate cu privire la momentul în care cealaltă ar recupera.
• Viteza ingineriei: Actualizările cheie și caracteristicile mult așteptate nu au fost livrate în timp util pe ambele platforme.

Unele dintre probleme s-au extins dincolo de mobil, iar răspunsul la acestea ar necesita o digresiune din domeniul tehnologiei în spațiul fascinant al problemelor de scalare organizațională și, în special, al startup-urilor tehnologice cu creștere rapidă. Dar fragilitatea ecosistemului mobil a fost foarte mult înrădăcinată în tehnologie și arhitectură.

Scalarea ingineriei mobile

Scalarea ingineriei mobile vine cu un set unic de provocări care sunt semnificativ diferite de scalarea echipelor backend și web. Aceste diferențe provin din fragmentarea platformei și realitățile operaționale ale ecosistemului mobil. Echipele mobile trebuie de obicei să ofere asistență pentru mai multe platforme pe o varietate de sisteme de operare și dispozitive (telefoane, tablete, uneori purtabile). iOS și Android vin cu propriile lor limbaje de programare, cadre și instrumente, ceea ce duce la cantități mari de efort duplicat: echipe multiple, baze de cod duplicate și compromisuri constante între munca specifică platformei și cea legată de produs. Menținerea ofertei de produse sincronizată necesită o cantitate enormă de coordonare.

Ceea ce este o provocare la nivelul întregii industrii a fost deosebit de acut pentru Proton. Aplicațiile de funcționalitate, cum ar fi Mail și Calendar, sunt inerent mai complexe decât majoritatea aplicațiilor mobile de pe piață. Când adăugați deasupra stratul suplimentar de logică client necesară pentru a gestiona criptarea de la un capăt la altul, ajungeți la clienți deosebit de „groși”. Pe vremuri, echipa Android era ocupată cu rescrierea Mail la standarde de calitate mai bune — o investiție care a durat cea mai mare parte a 18 luni. iOS avea, de asemenea, o nevoie urgentă de re-arhitecturare, ca să nu mai vorbim de Calendar. Costul duplicării consuma toate resursele noastre de inginerie și a devenit clar că nu vom reuși făcând mai mult din același lucru.

Cel mai bun lucru în a recunoaște că ești blocat este că acționează ca un factor de forțare pentru a gândi în afara constrângerilor actuale ale status quo-ului. Ce am face dacă am putea începe din nou, eliberați de povara alegerilor și angajamentelor care ne-au adus aici? Când analizați mai atent modul în care companiile de succes au tratat această problemă în deceniul precedent, realizați că au urmat una dintre cele două strategii posibile:

1. Au aruncat bani în problemă, construind echipe tot mai mari, deoarece costurile operaționale ridicate au fost compensate de o combinație de investiții fără fund și/sau randamente generoase. Aceasta nu a fost o opțiune pentru modelul de afaceri fără capital de risc al Proton: nu putem concura cu cheltuielile concurenților bazați pe reclame și susținuți de investitori.
2. Și-au reproiectat aplicațiile pentru a scăpa de risipă, ceea ce înseamnă construirea aplicațiilor folosind (pe cât posibil) o bază de cod partajată.

Opțiunea 1 fiind exclusă din start, calea de urmat a fost stabilită.

Un mijloc pentru un scop: alegerea stivei tehnologice potrivite

Următorul pas a fost alegerea unei stive tehnologice care ar putea face treaba.

În ultimii 15 ani, dezvoltarea mobilă multi-platformă a fost inundată cu soluții „universale”: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform și multe altele. Fiecare a sosit cu aceeași promisiune — de a înlocui complet dezvoltarea nativă. În practică, majoritatea fie au eșuat complet, fie au reușit doar în spații de probleme strict limitate. Nu există o abstracție universală care să facă diferențele dintre platforme să dispară: oricine a livrat și a întreținut aplicații mobile mari știe acest lucru. Singura cale sigură înainte este să lucrezi înapoi de la cerințele concrete, mai degrabă decât înainte de la tendințele instrumentelor.

Am tradus acel scop final într-un set de cerințe nenegociabile (1) pe care orice soluție aleasă trebuia să le satisfacă și le-am folosit ca cadru de ghidare pe parcursul procesului de evaluare:

1. Costuri și termene: Stiva trebuia să reducă material costul și timpul necesar pentru a livra, întreține și evolua Proton Mail pe iOS și Android.
2. Experiența utilizatorului: Trebuia să păstreze performanța și calitatea interacțiunii aproape native — orice mai puțin era exclus din start.
3. Pregătire strategică pentru viitor: Soluția trebuia să fie de lungă durată. Am fost intenționați în a evita cadrele terțe care ar face foaia noastră de parcurs dependentă de asistența continuă a unui alt furnizor.

Tensiunea dintre primele două constrângeri este versiunea industriei a sfântului graal: „O soluție multi-platformă care oferă performanța și experiența utilizatorului aplicațiilor native.”

Am fost sceptici de la început că React Native sau Flutter — cele două cadre multi-platformă dominante la acea vreme — ar putea îndeplini acest standard. Totuși, am validat acel scepticism construind implementări proof-of-concept ale vizualizării listei de mesaje din Mail.

React Native și-a dezvăluit rapid limitările. Derularea printr-un set mare de date a făcut evident costul modelului său de execuție interpretat. Flutter a performat mai bine, dar interfața de utilizare a rămas vizibil non-nativă, în special pe iOS. Mai important, Flutter este un cadru proprietar controlat de Google, care are un istoric(fereastră nouă) de abandonare a tehnologiilor interne și concediase recent o mare parte din echipa Flutter. Pentru un produs cu garanții de securitate și fiabilitate pe termen lung, acel nivel de dependență externă era inacceptabil.

Kotlin Multiplatform a fost următorul candidat. Este o opțiune convingătoare — în special pentru organizațiile cu expertiză Android profundă — dar în cele din urmă nu s-a ridicat la înălțimea cazului nostru de utilizare. Absența unui strat UI partajat, întrebările legate de maturitate și cheltuielile generale suplimentare introduse de modelul său de execuție au depășit beneficiile sale.

În acest moment, concluzia a fost clară și aliniată cu intuiția noastră inițială: singura arhitectură care se apropie constant de rezultatul dorit este o stivă deliberat mixtă. UI nativ pe fiecare platformă – Jetpack Compose pe Android, SwiftUI pe iOS – susținut de un strat de logică de afaceri partajat scris într-un limbaj de înaltă performanță, de nivel scăzut. Această abordare are un istoric: Dropbox a folosit faimos C++ pentru a partaja logica de afaceri pe platformele mobile înainte de a o abandona în 2019 din cauza costului operațional și cognitiv al limbajului.

Până la sfârșitul anului 2023, Rust a apărut clar ca succesor în linia limbajelor de programare a sistemelor.

Rust ocupă același cadru de performanță ca C++, dar fără multe dintre datoriile sale istorice. Oferă garanții puternice de siguranță a memoriei fără garbage collection, impune concurența thread-safe la compilare și este susținut de un ecosistem open-source mare și foarte competent. La fel de important, Rust se integrează curat cu limbajele mobile native — Swift și SwiftUI pe iOS, Kotlin și Jetpack Compose pe Android — făcându-l o alegere pragmatică pentru partajarea logicii de bază fără a compromite stratul UI.

Aceasta nu a fost o decizie lipsită de riscuri. La acea vreme, existau puține exemple de aplicații mobile la scară largă, orientate către consumatori, construite pe o arhitectură centrată pe Rust, iar experiența Rust în cadrul echipei era limitată.

Dar inovația semnificativă are loc rareori pe teritorii cu risc scăzut. Adevărata provocare nu a fost Rust în sine, ci inerția organizațională — trecerea de la abordări dovedite, conservatoare, la experimentare deliberată, ghidată de constrângeri clare și judecată inginerească.

Noul Proton Mail: rezultat și învățăminte

Să trecem rapid la ziua de azi și să vedem cum a decurs pariul.

Diagrama de mai jos reprezintă arhitectura Mail mobile. Nucleul Rust este responsabil pentru întreaga logică de afaceri a aplicației. Am împins utilizarea Rust dincolo de aplicațiile sale obișnuite (rețelistică, stocare, calcul algoritmic) până la gestionarea logicii complexe de navigare. Un caz concret este logica care guvernează derularea infinită a listei de mesaje. Deși neortodoxă, aceasta s-a dovedit esențială pentru atingerea obiectivului nostru de maximizare a reutilizării codului. Ca urmare, aproape 80% din baza de cod este acum partajată între iOS și Android.

S-a tradus acest lucru într-un timp de lansare pe piață mai rapid și de calitate superioară? Deși este încă prea devreme pentru un verdict final, semnele timpurii au fost foarte încurajatoare:

• În cele două luni care au urmat lansării, echipa a reușit să mențină o cadență săptămânală a actualizărilor de caracteristici pe ambele platforme (un total de 12 lansări de caracteristici).
• Am închis decalajele de caracteristici dintre platforme, aducând pe Android caracteristici mult așteptate, cum ar fi amânarea, RSVP calendar și swipe-to-next-message.
• Chiar și în acest stadiu incipient, noua bază de cod s-a dovedit mai stabilă decât generațiile anterioare pe ambele platforme: rata de blocare iOS este de 0,05% (în scădere de la 0,12%), în timp ce cea a Android a revenit la un nivel istoric de referință (0,19%). Aceasta este o susținere puternică a stabilității runtime a Rust.

Asistența scalează, de asemenea, mai eficient sub această abordare. Este adesea mai rapid să identificați și să rezolvați o singură cauză rădăcină partajată decât să urmăriți probleme superficial similare care decurg din defecte logice ușor diferite răspândite în două baze de cod independente. Am găsit confirmarea empirică a ceea ce fusese anterior o ipoteză de lucru în timp ce reparam o clasă de probleme de sincronizare a categoriilor care afectau logica ce stă la baza capabilităților deconectate ale aplicației: o singură cauză rădăcină, o singură soluție — reprezentată în diagrama de mai sus prin modulul de Rebasing livrat cu versiunea 7.6.2.

Cealaltă parte a monedei?

• Erorile și regresiile vor avea probabil un impact mai larg și vor afecta utilizatorii de pe ambele platforme. Nu puteți avea totul — dar puteți atenua cu siguranță riscul prin supra-indexarea testării end-to-end (E2E).
• Ca în cazul oricărei divizări a unei soluții orientate către utilizator de-a lungul unei diviziuni tehnologice orizontale, există riscul de a crea silozuri de cunoștințe și de a pierde o parte din concentrarea inginerească asupra experiențelor utilizatorilor de la un capăt la altul. Trebuie să fiți conștienți de acest lucru și să atenuați intenționat riscul. Printre cele mai eficiente măsuri:
  • Aliniați sub-echipele pentru a livra caracteristici, mai degrabă decât straturi tehnologice.
  • Instruiți inginerii de mobile să devină „full stack”, adică capabili să depaneze, să ofere asistență și să proiecteze atât pe baza de cod Rust, cât și pe platformele native.

Ce urmează pentru Transformarea Inginierească

Încă de la începutul acestui proiect, a fost clar că mizele se extindeau mult dincolo de Proton Mail. Aplicarea cu succes a acestei stive tehnologice la aplicația emblematică a Proton a fost întotdeauna intenționată ca un prim pas într-o călătorie mai lungă — una care ar vedea în cele din urmă această abordare implementată în restul ecosistemului nostru mobil.

Acel scenariu se desfășoară acum. În timp ce scriu acest articol, SDK-urile noastre pentru cont și plăți, precum și următoarea generație de aplicații mobile Proton Calendar, sunt rescrise în conformitate cu această nouă direcție tehnică.

Acest lucru marchează începutul unui al doilea val de transformare inginierească — o evoluție care extinde planul tehnologic cu un cadru arhitectural conceput pentru a face reutilizarea componentelor mai ușoară, nu numai între platforme, ci și între produse. Deși această tranziție nu se va întâmpla peste noapte, este fundamentală pentru construirea ecosistemului perfect integrat, axat pe confidențialitate, pe care clienții noștri îl așteaptă de la Proton.

(1): Simon Lewis,„O strategie pentru implementarea aplicațiilor pe multiple platforme”, 2023.