Protonin uudet Mail-mobiilisovellukset: enemmän kuin silmä näkee

Viime vuoden syyskuussa julkaisimme suuren päivityksen Proton Mail iOS:lle ja Androidille.

Pinnalla uudet sovellukset tarjoavat modernin muotoilun, paremman suorituskyvyn ja yhteydettömät ominaisuudet – mutta pinnan alla on paljon enemmän kuin silmä näkee. Kulissien takana sovellukset ovat Proton Mailin täydellinen uudelleenkirjoitus uudella teknologiapinolla, projekti joka kulkee sisäisellä nimellä Engineering Transformation. Termi uusi on harkittu, koska – parhaan tietomme mukaan – tämä on ensimmäinen kerta, kun valittua teknologiaa on käytetty vakiintuneen tuotantosovelluksen yhteydessä.

Tämän artikkelin tarkoituksena on valaista kiehtovaa matkaa, jonka tiimimme on käynyt läpi tämän vallankumouksen tekemisessä, ja vastata joihinkin kysymyksiin, joita yhteisömme on kysynyt meiltä matkan varrella. Ennen kaikkea taustalla oleva peruste on tarve muuttaa vallitsevaa tilaa.

Kuinka kaikki alkoi

Oivallus siitä, että asioiden oli muututtava, iski perjantai-iltana lokakuussa 2023. Se materialisoitui yllättävällä selkeydellä, mutta ei tyhjästä: se oli huipentuma kuukausista, jotka vietettiin yrittäen löytää yhteistä nimittäjää näennäisesti toisiinsa liittymättömille ongelmille, jotka vaikuttivat käyttäjiemme kokemukseen Mail- ja Calendar-mobiilituotteiden kanssa.

Yksinkertaistamisen riskillä voimme tiivistää kipupisteet kolmeen alueeseen:

• Laatu: Mail iOS ja Mail Android, erikseen tarkasteltuna, jäivät odotuksista laadun ja suorituskyvyn suhteen.
• Ominaisuusero iOS:n ja Androidin välillä: Jotkin ominaisuudet olivat saatavilla vain yhdellä alustalla, ilman selkeyttä siitä, milloin toinen ottaisi kiinni.
• Tekninen nopeus: Keskeisiä päivityksiä ja kauan odotettuja ominaisuuksia ei toimitettu oikea-aikaisesti molemmille alustoille.

Jotkin ongelmista ulottuivat mobiilin ulkopuolelle, ja niihin vastaaminen vaatisi poikkeamista teknologia-alueelta organisaation skaalaamisen kiehtovaan ongelma-avaruuteen, ja erityisesti nopeasti kasvaviin teknologia-alan starttiyrityksiin. Mutta mobiiliekosysteemin hauraus juurtui vahvasti teknologiaan ja arkkitehtuuriin.

Mobiilisuunnittelun skaalaaminen

Mobiilisuunnittelun skaalaaminen tuo mukanaan ainutlaatuisen joukon haasteita, jotka eroavat merkittävästi backend- ja verkkotiimien skaalaamisesta. Nämä erot johtuvat alustojen pirstoutumisesta ja mobiiliekosysteemin operatiivisista todellisuuksista. Mobiilitiimien on tyypillisesti tuettava useita alustoja eri käyttöjärjestelmissä ja laitteissa (puhelimet, tabletit, joskus puettavat laitteet). iOS ja Android tulevat omine ohjelmointikielineen, kehyksineen ja työkaluineen, mikä johtaa suureen määrään päällekkäistä työtä: useita tiimejä, päällekkäisiä koodikantoja ja jatkuvia kompromisseja alustakohtaisen ja tuotteeseen liittyvän työn välillä. Tuotetarjonnan pitäminen synkronoituna vaatii valtavan määrän koordinointia.

Mikä on alan laajuinen haaste, oli erityisen akuutti Protonille. Toiminnallisuuden sovellukset, kuten Mail ja Calendar, ovat luonnostaan monimutkaisempia kuin useimmat mobiilisovellukset markkinoilla. Kun lisätään päälle päästä päähän -salauksen käsittelyyn vaadittava ylimääräinen asiakaslogiikkakerros, päädytään erityisen ”paksuihin” asiakasohjelmiin. Aiemmin Android-tiimi oli kiireinen kirjoittamassa Mailia uudelleen parempiin laatustandardeihin – investointi, joka vei suurimman osan 18 kuukaudesta. iOS oli myös kipeästi uudelleenarkkitehtuurin tarpeessa, puhumattakaan Calendarista. Päällekkäisyyden kustannukset söivät kaikki suunnitteluresurssimme, ja kävi selväksi, ettemme onnistuisi tekemällä lisää samaa.

Parasta jumiutumisen tunnistamisessa on se, että se toimii pakottavana tekijänä ajatella nykyisen tilanteen rajoitusten ulkopuolella. Mitä tekisimme, jos voisimme aloittaa alusta, vapautettuna valintojen ja sitoumusten taakasta, jotka johtivat meidät tähän? Kun tarkastelette lähemmin, kuinka menestyvät yritykset käsittelivät tätä ongelmaa edellisellä vuosikymmenellä, huomaatte niiden noudattaneen yhtä vain kahdesta mahdollisesta strategiasta:

1. Ne heittivät rahaa ongelmaan, rakentaen yhä suurempia tiimejä, kun korkeita toimintakustannuksia kompensoitiin pohjattomilla investoinneilla ja/tai ylellisillä tuotoilla. Tämä ei ollut vaihtoehto Protonin VC-vapaalle liiketoimintamallille: emme voi kilpailla mainospohjaisten, sijoittajien tukemien kilpailijoiden kulutuksen kanssa.
2. Ne suunnittelivat sovelluksensa uudelleen päästäkseen eroon jätteestä, mikä tarkoittaa sovellusten rakentamista käyttäen (mahdollisimman paljon) jaettua koodikantaa.

Koska vaihtoehto 1 oli poissuljettu, tie eteenpäin oli selvä.

Keino päämäärään: oikean teknologiapinon valinta

Seuraava askel oli valita teknologiapino, joka voisi oikeasti hoitaa työn.

Viimeisten 15 vuoden aikana alustariippumaton mobiilikehitys on tulvinut ”yksi koko sopii kaikille” -ratkaisuja: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform ja monet muut. Jokainen saapui samalla lupauksella – korvata natiivikehitys kokonaan. Käytännössä useimmat joko epäonnistuivat täysin tai onnistuivat vain tiukasti rajoitetuissa ongelma-avaruuksissa. Ei ole olemassa universaalia abstraktiota, joka saa alustojen erot katoamaan: jokainen, joka on toimittanut ja ylläpitänyt suuria mobiilisovelluksia, tietää tämän. Ainoa luotettava tapa edetä on työskennellä taaksepäin konkreettisista vaatimuksista eikä eteenpäin työkalutrendeistä.

Käänsimme tuon lopputavoitteen joukoksi ehdottomia vaatimuksia (1), jotka minkä tahansa valitun ratkaisun oli täytettävä, ja käytimme niitä ohjaavana kehyksenämme koko arviointiprosessin ajan:

1. Kustannukset ja aikataulut: Pinon oli vähennettävä olennaisesti kustannuksia ja aikaa, joka vaaditaan Proton Mailin toimittamiseen, ylläpitämiseen ja kehittämiseen iOS:llä ja Androidilla.
2. Käyttäjäkokemus: Sen oli säilytettävä lähes natiivi suorituskyky ja vuorovaikutuksen laatu – mikä tahansa vähemmän oli poissuljettua.
3. Strateginen tulevaisuuden varmistaminen: Ratkaisun oli oltava pitkäikäinen. Olimme tarkoituksellisia välttääksemme kolmannen osapuolen kehyksiä, jotka tekisivät tiekartastamme riippuvaisen toisen toimittajan jatkuvasta tuesta.

Jännite kahden ensimmäisen rajoituksen välillä on alan versio Graalin maljasta: ”Alustariippumaton ratkaisu, joka tarjoaa natiivisovellusten suorituskyvyn ja käyttäjäkokemuksen.”

Olimme alusta alkaen skeptisiä sen suhteen, voisivatko React Native tai Flutter – kaksi hallitsevaa alustariippumatonta kehystä tuolloin – täyttää tämän vaatimuksen. Silti validoimme tuon skeptisyyden rakentamalla konseptitodistuksia Mailin viestiluettelonäkymästä.

React Native paljasti nopeasti rajoituksensa. Suuren tietojoukon selaaminen teki sen tulkitun suoritusmallin kustannuksista tuskallisen ilmeisiä. Flutter suoriutui paremmin, mutta käyttöliittymä pysyi näkyvästi ei-natiivina, erityisesti iOS:llä. Mikä tärkeämpää, Flutter on Googlen hallitsema omisteinen kehys, jolla on historiaa(uusi ikkuna) talon sisäisten teknologioiden hylkäämisessä, ja joka oli äskettäin irtisanonut suuren osan Flutter-tiimistä. Tuotteelle, jolla on pitkän aikavälin turvallisuus- ja luotettavuustakuut, tuo ulkoisen riippuvuuden taso ei ollut hyväksyttävää.

Kotlin Multiplatform oli seuraava ehdokas. Se on houkutteleva vaihtoehto – erityisesti organisaatioille, joilla on syvällistä Android-asiantuntemusta – mutta se jäi lopulta lyhyeksi käyttötapauksessamme. Jaetun käyttöliittymäkerroksen puuttuminen, kypsyysasteeseen liittyvät kysymykset ja sen suoritusmallin tuoma lisäkuorma painoivat enemmän kuin sen hyödyt.

Tässä vaiheessa johtopäätös oli selvä ja linjassa alkuperäisen intuitiomme kanssa: ainoa arkkitehtuuri, joka pääsee johdonmukaisesti lähelle haluttua lopputulosta, on tarkoituksellisesti sekoitettu pino. Natiivi käyttöliittymä kullakin alustalla – Jetpack Compose Androidilla, SwiftUI iOS:llä – jota tukee jaettu liiketoimintalogiikkakerros, joka on kirjoitettu korkean suorituskyvyn matalan tason kielellä. Tällä lähestymistavalla on näyttöä: Dropbox käytti kuuluisasti C++:aa jakaakseen liiketoimintalogiikkaa mobiilialustojen välillä ennen kuin luopui siitä vuonna 2019 kielen operatiivisten ja kognitiivisten kustannusten vuoksi.

Vuoden 2023 loppuun mennessä Rust oli selvästi noussut seuraajaksi järjestelmäohjelmointikielten sukulinjassa.

Rust toimii samalla suorituskykyalueella kuin C++, mutta ilman monia sen historiallisia rasitteita. Se tarjoaa vahvat muistiturvallisuustakuut ilman roskienkeruuta, pakottaa säieturvallisen samanaikaisuuden käännösaikana ja sitä tukee suuri, erittäin pätevä avoimen lähdekoodin ekosysteemi. Yhtä tärkeää on, että Rust integroituu puhtaasti natiiveihin mobiilikieliin – Swiftiin ja SwiftUI:hin iOS:llä, Kotliniin ja Jetpack Composeen Androidilla – mikä tekee siitä pragmaattisen valinnan ydinlogiikan jakamiseen vaarantamatta käyttöliittymäkerrosta.

Tämä ei ollut riskitön päätös. Tuolloin oli vain vähän esimerkkejä laajamittaisista, kuluttajille suunnatuista mobiilisovelluksista, jotka oli rakennettu Rust-keskeiselle arkkitehtuurille, ja Rust-kokemus tiimin sisällä oli rajallista.

Mutta merkittävä innovaatio tapahtuu harvoin matalan riskin alueella. Todellinen haaste ei ollut Rust itsessään, vaan organisaation inertia – siirtyminen todistetuista, konservatiivisista lähestymistavoista kohti tarkoituksellista kokeilua, jota ohjaavat selkeät rajoitukset ja tekninen harkinta.

Uusi Proton Mail: tulos ja opit

Kelataan eteenpäin tähän päivään ja katsotaan, miten uhkapeli kannatti.

Alla oleva kaavio kuvaa Mail-mobiilin arkkitehtuuria. Rust-ydin on vastuussa koko sovelluksen liiketoimintalogiikasta. Työnsimme Rustin käytön sen tavallisten sovellusten (verkotus, tallennus, algoritminen laskenta) ulkopuolelle aina monimutkaisen navigointilogiikan käsittelyyn asti. Esimerkkinä on logiikka, joka hallitsee viestiluettelon ääretöntä selausta. Vaikka epätavallinen, tämä osoittautui avaimeksi tavoitteemme saavuttamisessa koodin uudelleenkäytön maksimoimiseksi. Tuloksena lähes 80 % koodikannasta on nyt jaettu iOS:n ja Androidin välillä.

Kääntyikö tämä nopeammaksi, korkealaatuisemmaksi markkinoille tuloajaksi? Vaikka on vielä liian aikaista lopulliselle tuomiolle, varhaiset merkit ovat olleet erittäin rohkaisevia:

• Kahden kuukauden aikana julkaisun jälkeen tiimi onnistui ylläpitämään viikoittaista tahtia ominaisuuspäivityksissä molemmilla alustoilla (yhteensä 12 ominaisuusjulkaisua).
• Suljimme ominaisuuserot alustojen välillä tuomalla Androidille kauan odotettuja ominaisuuksia, kuten torkutuksen, kalenterin RSVP:n ja pyyhkäise-seuraavaan-viestiin -toiminnon.
• Jopa tässä varhaisessa vaiheessa uusi koodikanta on osoittautunut vakaammaksi kuin aiemmat sukupolvet molemmilla alustoilla: iOS:n kaatumisaste on 0,05 % (laskenut 0,12 %:sta), kun taas Androidin on palannut historialliseen perustasoon (0,19 %). Tämä on vahva osoitus Rustin suoritusajan vakaudesta.

Tuki myös skaalautuu tehokkaammin tällä lähestymistavalla. On usein nopeampaa tunnistaa ja ratkaista yksittäinen, jaettu perussyy kuin jahdata pinnallisesti samankaltaisia ongelmia, jotka johtuvat hieman erilaisista logiikkavirheistä kahdessa itsenäisessä koodikannassa. Löysimme empiirisen vahvistuksen sille, mikä oli aiemmin ollut työhypoteesi, korjatessamme luokan kategoriasynkronointiongelmia, jotka vaikuttivat logiikkaan, joka tukee sovelluksen yhteydettömiä ominaisuuksia: yksi perussyy, yksi ratkaisu – jota yllä olevassa kaaviossa edustaa Rebasing-moduuli, joka toimitettiin version 7.6.2 mukana.

Kolikon toinen puoli?

• Virheillä ja regressioilla on todennäköisesti laajempi vaikutus ja ne vaikuttavat käyttäjiin molemmilla alustoilla. Ette voi todella saada kaikkea – mutta voitte ehdottomasti lieventää riskiä panostamalla päästä päähän (E2E) -testaukseen.
• Kuten missä tahansa käyttäjälle suunnatun ratkaisun leikkaamisessa horisontaalista teknologiajakoa pitkin, on olemassa riski luoda tietosiiloja ja menettää jonkin verran suunnittelun keskittymistä päästä päähän -käyttäjäkokemuksiin. Teidän on oltava tietoisia tästä ja lievennettävä riskiä tarkoituksellisesti. Tehokkaimpia toimenpiteitä ovat:
  • Kohdistakaa alatiimit toimittamaan ominaisuuksia teknolgiakerrosten sijaan.
  • Kouluttakaa mobiili-insinöörejä tulemaan ”full stack” -osaajiksi, ts. kykeneviksi suorittamaan vianselvitystä, tukemaan ja suunnittelemaan sekä Rust-koodikannassa että natiiveilla alustoilla.

Mitä seuraavaksi Engineering Transformationille

Heti tämän projektin alusta lähtien oli selvää, että panokset ulottuivat paljon Proton Mailia laajemmalle. Tämän teknologiapinon menestyksekäs soveltaminen Protonin lippulaivasovellukseen oli aina tarkoitettu ensimmäiseksi askeleeksi pidemmällä matkalla – matkalla, joka lopulta näkisi tämän lähestymistavan käyttöönoton muualla mobiiliekosysteemissämme.

Tuo skenaario on nyt avautumassa. Kirjoittaessani tätä artikkelia, tili- ja maksu-SDK:mme sekä Proton Calendar -mobiilisovellusten seuraava sukupolvi kirjoitetaan uudelleen tämän uuden teknisen suunnan mukaisesti.

Tämä merkitsee toisen teknisen muutosallon alkua – evoluutiota, joka laajentaa teknologiasuunnitelmaa arkkitehtuurikehyksellä, joka on suunniteltu tekemään komponenttien uudelleenkäytöstä helpompaa, ei vain alustojen välillä vaan myös tuotteiden välillä. Vaikka tämä siirtymä ei tapahdu yhdessä yössä, se on perustavanlaatuista saumattomasti integroidun, yksityisyys edellä toimivan ekosysteemin rakentamiselle, jota asiakkaamme odottavat Protonin olevan.

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