V září loňského roku jsme spustili velkou aktualizaci aplikace Proton Mail pro iOS a Android.
Na povrchu nové aplikace přinášejí moderní design, lepší výkon a offline možnosti – ale je v tom mnohem víc, než se na první pohled zdá. V zákulisí jsou aplikace kompletním přepisem Proton Mailu na novém technologickém stacku, projektem, který nese interní název Engineering Transformation (Inženýrská transformace). Termín nový je záměrný, protože – podle našeho nejlepšího vědomí – to bylo poprvé, co byla zvolená technologie použita v kontextu zavedené produkční aplikace.
Tento článek si klade za cíl objasnit fascinující cestu, kterou náš tým prošel při vytváření této revoluce, a odpovědět na některé otázky, které nám naše komunita v průběhu cesty položila. Především je důvodem potřeba změnit status quo.
Jak to všechno začalo
Uvědomění, že se věci musí změnit, přišlo v pátek večer v říjnu 2023. Zhmotnilo se s překvapivou jasností, ale ne zčistajasna: bylo vyvrcholením měsíců strávených snahou najít společného jmenovatele pro zdánlivě nesouvisející problémy ovlivňující zkušenosti našich uživatelů s mobilními produkty Mail a Calendar (Kalendář).
S rizikem přílišného zjednodušení můžeme shrnout problematické body do tří oblastí:
- Kvalita: Mail pro iOS a Mail pro Android, bráno izolovaně, nenaplnily očekávání z hlediska kvality a výkonu.
- Rozdíl ve funkcích mezi iOS a Androidem: Některé funkce byly k dispozici pouze na jedné platformě, bez jasnosti, kdy je druhá dožene.
- Rychlost inženýrství: Klíčové aktualizace a dlouho očekávané funkce nebyly dodávány včas napříč oběma platformami.
Některé problémy sahaly za hranice mobilních zařízení a jejich zodpovězení by vyžadovalo odbočku z technologické domény do fascinujícího prostoru problémů organizačního škálování a zejména rychle rostoucích technologických start-upů. Křehkost mobilního ekosystému však byla velmi silně zakořeněna v technologii a architektuře.
Škálování mobilního inženýrství
Škálování mobilního inženýrství přináší jedinečnou sadu výzev, které se významně liší od škálování backendových a webových týmů. Tyto rozdíly pramení z fragmentace platforem a provozní reality mobilního ekosystému. Mobilní týmy obvykle potřebují podporovat více platforem napříč různými operačními systémy a zařízeními (telefony, tablety, někdy nositelná elektronika). iOS a Android přicházejí s vlastními programovacími jazyky, frameworky a nástroji, což vede k velkému množství duplicitního úsilí: více týmů, duplicitní kódové základny a neustálé kompromisy mezi prací specifickou pro platformu a prací související s produktem. Udržování nabídky produktů v synchronizaci vyžaduje obrovské množství koordinace.
To, co je výzvou pro celé odvětví, bylo pro Proton obzvláště naléhavé. Funkční aplikace jako Mail a Calendar jsou neodmyslitelně složitější než většina mobilních aplikací na trhu. Když k tomu přidáte další vrstvu klientské logiky potřebné pro obsluhu koncového šifrování, skončíte s obzvláště „tlustými“ klienty. Kdysi byl tým Androidu zaneprázdněn přepisováním Mailu do standardů lepší kvality – investice, která zabrala velkou část 18 měsíců. iOS také nutně potřeboval přepracovat architekturu, nemluvě o Kalendáři. Náklady na duplicitu užíraly všechny naše inženýrské zdroje a bylo jasné, že neuspějeme tím, že budeme dělat více téhož.
Nejlepší na tom, že si uvědomíte, že jste uvízli, je to, že to působí jako nátlakový faktor k přemýšlení mimo omezení vašeho současného status quo. Co bychom dělali, kdybychom mohli začít nanovo, osvobozeni od břemene voleb a závazků, které nás sem přivedly? Když se blíže podíváte na to, jak úspěšné společnosti řešily tento problém v předchozím desetiletí, zjistíte, že následovaly jednu z pouhých dvou možných strategií:
- Zahrnuli problém penězi, budovali stále větší týmy, protože vysoké provozní náklady byly kompenzovány kombinací bezedných investic a/nebo štědrých výnosů. To nebyla možnost pro obchodní model Protonu bez rizikového kapitálu (VC): nemůžeme soutěžit s výdaji konkurentů založených na reklamách a podporovaných investory.
- Přeorganizovali své aplikace, aby se zbavili plýtvání, což znamená budování aplikací pomocí (pokud možno) sdílené kódové základny.
Vzhledem k tomu, že možnost 1 byla neprůchodná, cesta vpřed byla daná.
Prostředek k dosažení cíle: výběr správného technologického stacku
Dalším krokem bylo vybrat technologický stack, který by tu práci skutečně zvládl.
Za posledních 15 let byl vývoj mobilních aplikací napříč platformami zaplaven „univerzálními“ řešeními: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform a mnoho dalších. Každé přišlo se stejným příslibem – zcela nahradit nativní vývoj. V praxi většina buď zcela selhala, nebo uspěla pouze v přísně omezených problémových prostorech. Neexistuje žádná univerzální abstrakce, díky které by rozdíly mezi platformami zmizely: každý, kdo vydal a udržoval velké mobilní aplikace, to ví. Jedinou spolehlivou cestou vpřed je pracovat zpětně od konkrétních požadavků, nikoli dopředu od trendů v nástrojích.
Tento konečný cíl jsme přeložili do souboru nesmlouvavých požadavků (1), které muselo jakékoli zvolené řešení splňovat, a použili jsme je jako náš vodící rámec během celého procesu hodnocení:
- Náklady a časové rámce: Stack musel podstatně snížit náklady a čas potřebný k vydání, údržbě a rozvoji Proton Mailu napříč iOS a Androidem.
- Uživatelská zkušenost: Muselo to zachovat výkon a kvalitu interakce blízkou nativní – cokoli menšího bylo nepřijatelné.
- Strategická připravenost na budoucnost: Řešení muselo mít dlouhou životnost. Záměrně jsme se vyhýbali frameworkům třetích stran, které by učinily náš plán závislým na neustálé podpoře jiného dodavatele.
Napětí mezi prvními dvěma omezeními je průmyslovou verzí svatého grálu: „Řešení napříč platformami, které poskytuje výkon a uživatelskou zkušenost nativních aplikací.“
Od začátku jsme byli skeptičtí k tomu, že by React Native nebo Flutter – dva dominantní frameworky pro různé platformy v té době – mohly tuto laťku splnit. Přesto jsme tuto skepsi ověřili vytvořením implementací „proof-of-concept“ zobrazení seznamu zpráv Mailu.
React Native rychle odhalil svá omezení. Posouvání velkým souborem dat učinilo náklady jeho modelu interpretovaného provádění bolestně zřejmými. Flutter si vedl lépe, ale uživatelské rozhraní zůstalo viditelně nenativní, zejména na iOS. Co je důležitější, Flutter je proprietární framework ovládaný společností Google, která má historii(nové okno) opouštění interních technologií a nedávno propustila velkou část týmu Flutter. Pro produkt se zárukami dlouhodobé bezpečnosti a spolehlivosti byla taková úroveň externí závislosti nepřijatelná.
Dalším kandidátem byl Kotlin Multiplatform. Je to přesvědčivá možnost – zejména pro organizace s hlubokými zkušenostmi s Androidem – ale pro náš případ použití nakonec nedostačovala. Absence sdílené vrstvy uživatelského rozhraní, otázky kolem vyspělosti a dodatečná režie zavedená jeho modelem provádění převážily nad jeho výhodami.
V tomto bodě byl závěr jasný a v souladu s naší původní intuicí: jedinou architekturou, která se konzistentně blíží požadovanému výsledku, je záměrně smíšený stack. Nativní UI na každé platformě – Jetpack Compose na Androidu, SwiftUI na iOS – podpořené sdílenou vrstvou obchodní logiky napsanou ve vysoce výkonném nízkoúrovňovém jazyce. Tento přístup má svou historii: Dropbox slavně používal C++ ke sdílení obchodní logiky napříč mobilními platformami, než jej v roce 2019 opustil kvůli provozním a kognitivním nákladům jazyka.
Koncem roku 2023 se Rust jasně vynořil jako nástupce v linii systémových programovacích jazyků.
Rust zaujímá stejnou výkonnostní obálku jako C++, ale bez mnoha jeho historických závazků. Poskytuje silné záruky bezpečnosti paměti bez garbage collection, vynucuje vláknově bezpečnou souběžnost v době kompilace a je podporován velkým, vysoce kompetentním ekosystémem open source. Stejně důležité je, že se Rust čistě integruje s nativními mobilními jazyky – Swift a SwiftUI na iOS, Kotlin a Jetpack Compose na Androidu – což z něj činí pragmatickou volbu pro sdílení základní logiky bez kompromitování vrstvy UI.
Nebylo to rozhodnutí bez rizika. V té době existovalo jen málo příkladů rozsáhlých mobilních aplikací určených pro spotřebitele postavených na architektuře zaměřené na Rust a zkušenosti s Rustem v týmu byly omezené.
Ale smysluplná inovace se jen zřídka děje na území s nízkým rizikem. Skutečnou výzvou nebyl samotný Rust, ale organizační setrvačnost – posun od osvědčených, konzervativních přístupů k záměrnému experimentování, vedenému jasnými omezeními a inženýrským úsudkem.
Nový Proton Mail: výsledek a ponaučení
Převiňme do dneška a podívejme se, jak ten risk dopadl.
Níže uvedený diagram představuje architekturu Mail mobile. Jádro v Rustu je zodpovědné za veškerou obchodní logiku aplikace. Posunuli jsme použití Rustu nad rámec jeho obvyklých aplikací (síťování, úložiště, algoritmické výpočty) až ke zpracování složité navigační logiky. Příkladem je logika řídící nekonečné posouvání seznamu zpráv. Ačkoli je to neortodoxní, ukázalo se to jako klíčové pro dosažení našeho cíle maximalizovat opětovné použití kódu. V důsledku toho je nyní téměř 80 % kódové základny sdíleno napříč iOS a Androidem.
Promítlo se to do rychlejšího a kvalitnějšího uvedení na trh? I když je ještě příliš brzy na konečný verdikt, první známky jsou velmi povzbudivé:
- Během dvou měsíců po vydání se týmu podařilo udržet týdenní kadenci aktualizací funkcí napříč oběma platformami (celkem 12 vydání funkcí).
- Odstranili jsme rozdíly ve funkcích mezi platformami a přinesli na Android dlouho očekávané funkce, jako je odložení (snooze), RSVP v kalendáři a přejetí prstem na další zprávu.
- I v této rané fázi se nová kódová základna ukázala stabilnější než předchozí generace na obou platformách: míra pádů na iOS je 0,05 % (pokles z 0,12 %), zatímco na Androidu je zpět na historickém minimu (0,19 %). To je silné potvrzení stability runtime Rustu.
Podpora se při tomto přístupu také škáluje efektivněji. Často je rychlejší identifikovat a vyřešit jednu sdílenou kořenovou příčinu než pronásledovat povrchně podobné problémy vyplývající z mírně odlišných logických chyb roztroušených ve dvou nezávislých kódových základnách. Našli jsme empirické potvrzení toho, co bylo dříve pracovní hypotézou, při opravě třídy problémů se synchronizací kategorií ovlivňujících logiku, o kterou se opírají offline možnosti aplikace: jedna kořenová příčina, jedno řešení – znázorněné v diagramu výše modulem Rebasing dodaným s verzí 7.6.2.
Druhá strana mince?
- Chyby (bugs) a regrese budou mít pravděpodobně širší dopad a ovlivní uživatele na obou platformách. Nemůžete mít opravdu všechno – ale rozhodně můžete zmírnit riziko nadměrným zaměřením na koncové (E2E) testování.
- Stejně jako u jakéhokoli krájení uživatelského řešení podél horizontálního technologického předělu existuje riziko vytvoření znalostních sil a ztráty určitého inženýrského zaměření na koncové uživatelské zkušenosti. Musíte si toho být vědomi a záměrně riziko zmírňovat. Mezi nejúčinnější opatření patří:
- Slaďte dílčí týmy tak, aby dodávaly funkce spíše než technologické vrstvy.
- Vyškolte mobilní inženýry, aby se stali „full stack“, tj. schopnými ladit, podporovat a tvořit napříč kódovou základnou v Rustu i nativními platformami.
Co bude dál s inženýrskou transformací
Od samého počátku tohoto projektu bylo jasné, že sázky sahají daleko za hranice samotného Proton Mailu. Úspěšné uplatnění tohoto technologického stacku na vlajkovou aplikaci Protonu bylo vždy zamýšleno jako první krok na delší cestě – té, která by nakonec vedla k zavedení tohoto přístupu ve zbytku našeho mobilního ekosystému.
Tento scénář se nyní odvíjí. Zatímco píši tento článek, naše SDK pro účet a platby, stejně jako příští generace mobilních aplikací Proton Calendar, jsou přepisovány v souladu s tímto novým technickým směrem.
To znamená začátek druhé vlny inženýrské transformace – evoluce, která rozšiřuje technologický plán o architektonický rámec navržený tak, aby usnadnil opětovné použití komponent, a to nejen napříč platformami, ale také napříč produkty. Ačkoli k tomuto přechodu nedojde přes noc, je zásadní pro vybudování hladce integrovaného ekosystému zaměřeného na soukromí, který naši zákazníci od Protonu očekávají.
(1): Simon Lewis,“A strategy for application implementation on multiple platforms”, 2023.
