Pada bulan September tahun lalu, kami meluncurkan pembaruan besar Proton Mail untuk iOS dan Android.
Di permukaan, aplikasi baru ini menghadirkan desain modern, performa yang lebih baik, dan kemampuan luring—tetapi ada lebih banyak hal dari yang terlihat. Di balik layar, aplikasi ini merupakan penulisan ulang lengkap Proton Mail pada tumpukan teknologi baru, sebuah proyek yang dinamai secara internal sebagai Engineering Transformation. Istilah baru sengaja digunakan karena — sepanjang pengetahuan kami — ini adalah pertama kalinya teknologi yang dipilih digunakan dalam konteks aplikasi produksi yang sudah mapan.
Artikel ini bertujuan untuk menyoroti perjalanan menarik yang telah dilalui tim kami dalam mewujudkan revolusi ini, dan untuk menjawab beberapa pertanyaan yang diajukan komunitas kami selama proses ini berlangsung. Pertama dan terpenting, alasan di baliknya adalah kebutuhan untuk mengubah status quo.
Bagaimana awal mulanya
Kesadaran bahwa banyak hal perlu berubah muncul pada suatu Jumat malam di bulan Oktober 2023. Kesadaran itu terwujud dengan kejelasan yang mengejutkan, tetapi tidak terjadi begitu saja: ini adalah puncak dari bulan-bulan yang dihabiskan untuk mencoba menemukan kesamaan dari masalah-masalah yang tampaknya tidak terkait yang memengaruhi pengalaman pengguna kami dengan produk seluler Mail dan Calendar.
Dengan risiko terlalu menyederhanakan, kami dapat merangkum poin-poin masalah dalam tiga area:
Kualitas: Mail iOS dan Mail Android, jika dilihat secara terpisah, tidak memenuhi ekspektasi dalam hal kualitas dan performa.
Kesenjangan fitur antara iOS dan Android: Beberapa fitur hanya tersedia di satu platform, tanpa kejelasan kapan platform lainnya akan menyusul.
Kecepatan rekayasa: Pembaruan utama dan fitur yang telah lama dinantikan tidak dihadirkan secara tepat waktu di kedua platform.
Beberapa isu meluas ke luar perangkat seluler, dan untuk menjawabnya akan memerlukan pengalihan dari domain teknologi ke ruang masalah penskalaan organisasi yang menarik, dan khususnya perusahaan rintisan teknologi yang berkembang pesat. Namun, kerentanan ekosistem seluler sangat berakar pada teknologi dan arsitektur.
Menskalakan rekayasa seluler
Melakukan penskalaan rekayasa seluler membawa serangkaian tantangan unik yang berbeda secara signifikan dari penskalaan tim backend dan web. Perbedaan ini berasal dari fragmentasi platform dan realitas operasional ekosistem seluler. Tim seluler biasanya perlu mendukung beberapa platform di berbagai sistem operasi dan perangkat (ponsel, tablet, terkadang perangkat yang dapat dikenakan). iOS dan Android hadir dengan bahasa pemrograman, framework, dan perkakas mereka sendiri, yang menyebabkan banyak upaya ganda: beberapa tim, codebase yang terduplikasi, dan trade-off konstan antara pekerjaan khusus platform dan pekerjaan terkait produk. Menjaga agar penawaran produk tetap sinkron membutuhkan koordinasi yang sangat besar.
Apa yang menjadi tantangan di seluruh industri sangat dirasakan oleh Proton. Aplikasi fungsionalitas seperti Mail dan Calendar secara inheren lebih kompleks daripada sebagian besar aplikasi seluler di pasar. Ketika ditambahkan lapisan logika klien tambahan yang diperlukan untuk menangani enkripsi end-to-end, hasilnya adalah klien yang sangat “tebal”. Dulu, tim Android sibuk menulis ulang Mail ke standar kualitas yang lebih baik—investasi yang memakan waktu sebagian besar dari 18 bulan. iOS juga sangat membutuhkan arsitektur ulang, belum lagi Calendar. Biaya duplikasi menghabiskan semua sumber daya rekayasa kami, dan menjadi jelas bahwa kami tidak akan berhasil jika terus melakukan hal yang sama.
Hal terbaik tentang menyadari bahwa kami buntu adalah hal itu bertindak sebagai faktor pemaksa untuk berpikir di luar batasan status quo kami saat ini. Apa yang akan kami lakukan jika kami bisa memulai dari awal, bebas dari beban pilihan dan komitmen yang membawa kami ke sini? Ketika melihat lebih dekat bagaimana perusahaan-perusahaan sukses menangani isu ini dalam dekade sebelumnya, Anda menyadari bahwa mereka mengikuti salah satu dari hanya dua strategi yang memungkinkan:
- Mereka menggelontorkan banyak uang untuk masalah tersebut, membangun tim yang semakin besar karena biaya operasional yang tinggi diimbangi oleh kombinasi investasi tanpa batas dan/atau pengembalian yang mewah. Ini bukan pilihan bagi model bisnis bebas modal ventura atau VC dari Proton: kami tidak dapat bersaing dengan pengeluaran kompetitor yang didukung iklan dan didukung investor.
- Mereka merekayasa ulang aplikasi untuk membuang kesia-siaan, yang berarti membangun aplikasi dengan menggunakan (sebanyak mungkin) codebase bersama.
Dengan opsi 1 yang tidak mungkin dilakukan, jalur di depan pun telah ditetapkan.
Sebuah sarana untuk mencapai tujuan: memilih tumpukan teknologi yang tepat
Langkah berikutnya adalah memilih tumpukan teknologi yang benar-benar dapat melakukan pekerjaan tersebut.
Selama 15 tahun terakhir, pengembangan seluler lintas platform telah dibanjiri dengan solusi “satu ukuran untuk semua”: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform, dan banyak lainnya. Masing-masing hadir dengan janji yang sama—untuk menggantikan pengembangan native sepenuhnya. Dalam praktiknya, sebagian besar gagal sama sekali atau hanya berhasil dalam ruang masalah yang sangat terbatas. Tidak ada abstraksi universal yang membuat perbedaan platform menghilang: siapa pun yang telah merilis dan memelihara aplikasi seluler besar mengetahui hal ini. Satu-satunya jalan keluar yang andal adalah bekerja mundur dari persyaratan konkret, alih-alih melangkah maju berdasarkan tren perkakas.
Kami menerjemahkan tujuan akhir tersebut menjadi serangkaian persyaratan yang tidak dapat ditawar (1) yang harus dipenuhi oleh solusi apa pun yang dipilih, dan menggunakannya sebagai kerangka panduan kami di sepanjang proses evaluasi:
- Biaya dan skala waktu: Tumpukan teknologi tersebut harus secara material mengurangi biaya dan waktu yang dibutuhkan untuk mengirim, memelihara, dan mengembangkan Proton Mail di iOS dan Android.
- Pengalaman pengguna: Hal tersebut harus mempertahankan performa yang mendekati native dan kualitas interaksi—apa pun yang kurang dari itu tidak dapat diterima.
- Kesiapan masa depan strategis: Solusi tersebut harus berumur panjang. Kami sengaja menghindari framework pihak ketiga yang akan membuat peta jalan kami bergantung pada dukungan berkelanjutan dari vendor lain.
Ketegangan antara dua batasan pertama adalah versi cawan suci dari industri ini: “Solusi lintas platform yang menghadirkan performa dan pengalaman pengguna seperti aplikasi native.”
Kami sejak awal skeptis bahwa React Native atau Flutter—dua framework lintas platform yang dominan saat itu—dapat memenuhi standar ini. Meskipun demikian, kami memvalidasi skeptisisme tersebut dengan membangun implementasi bukti konsep dari tampilan daftar pesan Mail.
React Native dengan cepat menunjukkan keterbatasannya. Menggulir daftar data yang besar membuat biaya model eksekusi yang diinterpretasikannya terlihat sangat jelas. Flutter memiliki performa yang lebih baik, tetapi UI-nya masih tampak jelas non-native, terutama di iOS. Yang lebih penting, Flutter adalah framework kepemilikan yang dikendalikan oleh Google, yang memiliki sejarah(jendela baru) mengabaikan teknologi in-house mereka dan baru-baru ini melakukan PHK terhadap sebagian besar tim Flutter. Untuk produk dengan jaminan keamanan dan keandalan jangka panjang, tingkat ketergantungan eksternal seperti itu tidak dapat diterima.
Kotlin Multiplatform adalah kandidat berikutnya. Ini adalah opsi yang menarik—terutama untuk organisasi dengan keahlian Android yang mendalam—but it ultimately fell short for our use case. Tidak adanya lapisan UI bersama, pertanyaan seputar kematangan, dan overhead tambahan yang ditimbulkan oleh model eksekusinya melebihi manfaat yang ditawarkan.
Pada titik ini, kesimpulannya jelas dan selaras dengan intuisi awal kami: satu-satunya arsitektur yang secara konsisten mendekati hasil yang diinginkan adalah tumpukan teknologi yang sengaja dicampur. UI native pada setiap platform – Jetpack Compose di Android, SwiftUI di iOS – didukung oleh lapisan logika bisnis bersama yang ditulis dalam bahasa tingkat rendah berkinerja tinggi. Pendekatan ini memiliki rekam jejak: Dropbox terkenal menggunakan C++ untuk membagikan logika bisnis di seluruh platform seluler sebelum mengabaikannya pada tahun 2019 karena biaya operasional dan kognitif dari bahasa tersebut.
Pada akhir tahun 2023, Rust telah muncul dengan jelas sebagai penerus dalam silsilah bahasa pemrograman sistem.
Rust menempati cakupan performa yang sama dengan C++, tetapi tanpa banyak liabilitas historisnya. Rust memberikan jaminan keamanan memori yang kuat tanpa garbage collection, menerapkan konkurensi thread-safe pada saat kompilasi, dan didukung oleh ekosistem open-source yang besar dan sangat kompeten. Yang tidak kalah penting, Rust berintegrasi dengan bersih dengan bahasa seluler native—Swift dan SwiftUI di iOS, Kotlin dan Jetpack Compose di Android—menjadikannya pilihan pragmatis untuk membagikan logika inti tanpa mengompromikan lapisan UI.
Ini bukan keputusan yang bebas risiko. Pada saat itu, hanya ada sedikit contoh aplikasi seluler berskala besar yang berhadapan langsung dengan konsumen yang dibangun di atas arsitektur yang berpusat pada Rust, dan pengalaman Rust dalam tim kami masih terbatas.
Namun, inovasi yang berarti jarang terjadi di wilayah berisiko rendah. Tantangan sebenarnya bukanlah Rust itu sendiri, melainkan inersia organisasi—beralih dari pendekatan konservatif yang terbukti menuju eksperimentasi yang disengaja, dipandu oleh batasan yang jelas dan penilaian rekayasa.
Proton Mail Baru: Hasil dan Pembelajaran
Mari kita langsung menuju hari ini dan melihat bagaimana hasil dari pertaruhan tersebut.
Diagram di bawah ini menggambarkan arsitektur seluler Mail. Inti Rust bertanggung jawab atas keseluruhan logika bisnis aplikasi. Kami mendorong penggunaan Rust melampaui aplikasi biasanya (jaringan, penyimpanan, komputasi algoritmik) hingga penanganan logika navigasi yang kompleks. Contoh kasusnya adalah logika yang mengatur pengguliran tanpa batas dari daftar pesan. Meskipun tidak biasa, ini terbukti menjadi kunci untuk mencapai tujuan kami dalam memaksimalkan penggunaan kembali kode. Hasilnya, hampir 80% dari codebase kini dibagikan di iOS dan Android.
Apakah ini menghasilkan waktu ke pasar yang lebih cepat dan berkualitas lebih tinggi? Meskipun masih terlalu dini untuk memberikan penilaian akhir, tanda-tanda awal sangat membesarkan hati:
- Dalam dua bulan setelah rilis, tim berhasil mempertahankan ritme mingguan pembaruan fitur di kedua platform (total 12 rilis fitur).
- Kami menutup kesenjangan fitur antar platform, menghadirkan fitur-fitur yang telah lama dinanti ke Android seperti tunda, RSVP kalender, dan geser ke pesan berikutnya.
- Bahkan pada tahap awal ini, codebase baru telah terbukti lebih stabil daripada generasi sebelumnya di kedua platform: tingkat crash iOS adalah 0,05% (turun dari 0,12%), sementara Android kembali ke baseline historisnya (0,19%). Ini adalah pengakuan kuat atas stabilitas runtime Rust.
Dukungan juga berskala lebih efektif di bawah pendekatan ini. Sering kali lebih cepat untuk mengidentifikasi dan menyelesaikan satu akar penyebab bersama daripada mengejar masalah yang tampak mirip secara dangkal yang timbul dari cacat logika yang sedikit berbeda yang tersebar di dua codebase independen. Kami menemukan konfirmasi empiris dari apa yang sebelumnya merupakan hipotesis kerja saat memperbaiki kelas masalah sinkronisasi kategori yang memengaruhi logika yang mendasari kemampuan luring aplikasi: satu akar penyebab, satu solusi—diwakili dalam diagram di atas oleh modul Rebasing yang disertakan pada versi 7.6.2.
Sisi lain dari koin tersebut?
- Bug dan regresi kemungkinan memiliki dampak yang lebih luas dan memengaruhi pengguna di kedua platform. Kita tidak bisa mendapatkan semuanya—tetapi risiko tentu dapat dimitigasi dengan melakukan pengujian end-to-end (E2E) secara intensif.
- Seperti halnya pemisahan solusi yang berhadapan langsung dengan pengguna di sepanjang pembagian teknologi horizontal, ada risiko terciptanya silo pengetahuan dan hilangnya fokus rekayasa pada pengalaman pengguna end-to-end. Hal ini perlu disadari dan dimitigasi secara sengaja. Di antara langkah-langkah yang paling efektif:
- Menyelaraskan sub-tim untuk menghadirkan fitur daripada lapisan teknologi.
- Melatih insinyur seluler untuk menjadi “full stack”, yaitu mampu melakukan debug, mendukung, dan merekayasa baik di seluruh codebase Rust maupun platform native.
Apa Selanjutnya untuk Engineering Transformation
Sejak awal proyek ini, jelas bahwa taruhannya meluas jauh melampaui Proton Mail saja. Keberhasilan penerapan tumpukan teknologi ini ke aplikasi andalan Proton selalu dimaksudkan sebagai langkah pertama dalam perjalanan yang lebih panjang—yang pada akhirnya akan membuat pendekatan ini diterapkan di seluruh sisa ekosistem seluler kami.
Skenario tersebut kini sedang berlangsung. Saat saya menulis artikel ini, SDK Akun dan Pembayaran kami, serta generasi berikutnya dari aplikasi seluler Proton Calendar, sedang ditulis ulang sejalan dengan arah teknis baru ini.
Ini menandai dimulainya gelombang kedua transformasi rekayasa—sebuah evolusi yang memperluas cetak biru teknologi dengan kerangka kerja arsitektur yang dirancang untuk mempermudah penggunaan kembali komponen, tidak hanya di seluruh platform tetapi juga di seluruh produk. Meskipun transisi ini tidak akan terjadi dalam semalam, ini sangat mendasar untuk membangun ekosistem terintegrasi dengan mulus yang mengutamakan privasi yang diharapkan pelanggan dari Proton.
(1): Simon Lewis,“A strategy for application implementation on multiple platforms”, 2023.
