Proton’un yeni Mail mobil uygulamaları: göründüğünden çok daha fazlası

Geçen yılın Eylül ayında, iOS ve Android için Proton Mail’in büyük bir güncellemesini başlattık.

Yüzeyde, yeni uygulamalar modern bir tasarım, daha iyi performans ve çevrim dışı yetenekler sunuyor—ancak göründüğünden çok daha fazlası var. Sahnelerin arkasında, uygulamalar yeni bir teknoloji yığını üzerinde Proton Mail’in tam bir yeniden yazımıdır; bu proje dahili olarak Mühendislik Dönüşümü adıyla anılmaktadır. Yeni terimi kasıtlıdır, çünkü — bildiğimiz kadarıyla — seçilen teknoloji yerleşik bir üretim uygulaması bağlamında ilk kez kullanılmıştır.

Bu makale, ekibimizin bu devrimin yapımında geçirdiği büyüleyici yolculuğa ışık tutmayı ve topluluğumuzun yol boyunca bize sorduğu bazı soruları yanıtlamayı amaçlamaktadır. Her şeyden önce, arkasındaki mantık statükoyu değiştirme ihtiyacıdır.

Her şey nasıl başladı

Bir şeylerin değişmesi gerektiğinin farkına varılması Ekim 2023’te bir Cuma akşamı oldu. Şaşırtıcı bir netlikle somutlaştı, ancak durup dururken olmadı: kullanıcılarımızın Mail ve Calendar mobil ürünleri deneyimini etkileyen görünüşte ilgisiz sorunlar için ortak bir payda bulmaya çalışarak geçirilen ayların doruk noktasıydı.

Aşırı basitleştirme riskiyle, sorunlu noktaları üç alanda özetleyebiliriz:

• Kalite: Mail iOS ve Mail Android, tek başlarına ele alındığında, kalite ve performans açısından beklentilerin altında kalıyordu.
• iOS ve Android arasındaki özellik boşluğu: Bazı özellikler yalnızca bir platformda mevcuttu ve diğerinin ne zaman yetişeceği konusunda netlik yoktu.
• Mühendislik hızı: Önemli güncellemeler ve uzun zamandır beklenen özellikler her iki platformda da zamanında teslim edilmiyordu.

Sorunlardan bazıları mobilin ötesine uzanıyordu ve bunları yanıtlamak teknoloji alanından örgütsel ölçeklendirmenin büyüleyici sorun alanına, özellikle de hızlı büyüyen teknoloji başlangıçlarına bir sapmayı gerektirecekti. Ancak mobil ekosistemin kırılganlığı büyük ölçüde teknoloji ve mimariye dayanıyordu.

Mobil Mühendisliği Ölçeklendirme

Mobil mühendisliği ölçeklendirme, arka uç ve web ekiplerini ölçeklendirmekten anlamlı ölçüde farklı olan kendine özgü bir dizi zorlukla birlikte gelir. Bu farklılıklar, platform parçalanmasından ve mobil ekosistemin operasyonel gerçeklerinden kaynaklanmaktadır. Mobil ekiplerin genellikle çeşitli işletim sistemleri ve cihazlar (telefonlar, tabletler, bazen giyilebilir cihazlar) genelinde birden fazla platformu desteklemesi gerekir. iOS ve Android, kendi programlama dilleri, çerçeveleri ve araçlarıyla birlikte gelir; bu da büyük miktarda tekrarlanan çabaya yol açar: birden fazla ekip, kopyalanmış kod tabanları ve platforma özgü ve ürünle ilgili işler arasında sürekli ödünleşimler. Ürün teklifini senkronize tutmak muazzam miktarda koordinasyon gerektirir.

Endüstri çapında bir zorluk olan şey Proton için özellikle şiddetliydi. Mail ve Calendar gibi işlevsellik uygulamaları piyasadaki çoğu mobil uygulamadan doğal olarak daha karmaşıktır. Uçtan uca şifrelemeyi işlemek (takma ad) için gereken ek istemci mantığı katmanını eklediğinizde, özellikle “kalın” istemcilerle karşılaşırsınız. O zamanlar Android ekibi, Mail’i daha iyi kalite standartlarına göre yeniden yazmakla meşguldü—18 ayın büyük bir kısmını alan bir yatırım. iOS da Calendar’dan bahsetmeye bile gerek yok, yeniden mimariye şiddetle ihtiyaç duyuyordu. Tekrarlamanın maliyeti tüm mühendislik kaynaklarımızı tüketiyordu ve aynı şeyden daha fazlasını yaparak başarılı olamayacağımız açık (temizle) hale geldi.

Sıkıştığınızı kabul etmenin en iyi yanı, mevcut statükonuzun kısıtlamalarının dışında düşünmek için zorlayıcı bir faktör görevi görmesidir. Sizi buraya getiren seçimlerin ve taahhütlerin yükünden kurtulmuş olarak yeniden başlayabilseydik ne yapardık? Başarılı şirketlerin önceki on yılda bu sorunla nasıl başa çıktığına daha yakından baktığınızda, yalnızca iki olası stratejiden birini izlediklerini fark edersiniz:

1. Soruna para saçtılar, yüksek işletme maliyetleri dipsiz yatırımlar ve/veya cömert getirilerin bir kombinasyonu ile dengelendiğinden daha da büyük ekipler kurdular. Bu, Proton’un VC içermeyen iş modeli için bir seçenek değildi: reklam tabanlı, yatırımcı destekli rakiplerin harcamalarıyla rekabet edemeyiz.
2. İsraftan kurtulmak için uygulamalarını yeniden tasarladılar, yani (mümkün olduğunca) paylaşılan bir kod tabanı kullanarak uygulamalar oluşturdular.

Seçenek 1 başlangıç bile olamayacağı için önümüzdeki yol belirlendi.

Bir amaca giden araç: doğru teknoloji yığınını seçmek

Bir sonraki adım, işi gerçekten yapabilecek bir teknoloji yığını seçmekti.

Son 15 yılda, platformlar arası mobil geliştirme “herkese uyan tek beden” çözümlerle dolup taştı: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform ve diğerleri. Her biri aynı vaatle geldi—yerel geliştirmeyi tamamen değiştirmek. Pratikte çoğu ya tamamen başarısız oldu ya da yalnızca sıkı bir şekilde kısıtlanmış sorun alanlarında başarılı oldu. Platform farklılıklarını ortadan kaldıran evrensel bir soyutlama yoktur: büyük mobil uygulamalar iletmiş (sunmuş) ve sürdürmüş herkes bunu bilir. İlerlemenin tek güvenilir yolu, araç trendlerinden ileriye doğru değil, somut gereksinimlerden geriye doğru çalışmaktır.

Bu nihai hedefi, seçilen herhangi bir çözümün karşılaması gereken bir dizi pazarlık edilemez gereksinime (1) çevirdik ve bunları değerlendirme süreci boyunca rehber çerçevemiz olarak kullandık:

1. Maliyetler ve zaman çizelgeleri: Yığın, Proton Mail’i iOS ve Android genelinde sunmak (iletmek), sürdürmek ve geliştirmek için gereken maliyeti ve zamanı maddi olarak azaltmak zorundaydı.
2. Kullanıcı deneyimi: yerele yakın performansı ve etkileşim kalitesini korumak zorundaydı—daha azı başlangıç bile olamazdı.
3. Stratejik geleceğe hazırlık: Çözüm uzun ömürlü olmalıydı. Yol haritamızı başka bir satıcının sürekli desteğine bağımlı hale getirecek üçüncü taraf çerçevelerden kaçınma konusunda kasıtlı davrandık.

İlk iki kısıtlama arasındaki gerilim, endüstrinin kutsal kase versiyonudur: “Yerel uygulamaların performansını ve kullanıcı deneyimini sunan platformlar arası bir çözüm.”

En başından beri, o zamanlar baskın platformlar arası çerçeveler olan React Native veya Flutter’ın bu çıtayı karşılayabileceğinden şüpheliydik. Yine de, Mail’in ileti listesi görünümünün kavram kanıtı uygulamalarını oluşturarak bu şüpheciliği doğruladık.

React Native sınırlamalarını hızla ortaya koydu. Büyük bir veri kümesinde gezinmek, yorumlanmış yürütme modelinin maliyetini acı verici bir şekilde belirgin hale getirdi. Flutter daha iyi performans gösterdi, ancak UI özellikle iOS’ta gözle görülür şekilde yerel değildi. Daha da önemlisi, Flutter, şirket içi teknolojileri terk etme geçmişine(yeni pencere) sahip olan ve yakın zamanda Flutter ekibinin büyük bir bölümünü işten çıkaran Google tarafından kontrol edilen tescilli bir çerçevedir. Uzun vadeli güvenlik ve güvenilirlik garantilerine sahip bir ürün için, bu düzeyde bir dış bağımlılık kabul edilemezdi.

Kotlin Multiplatform bir sonraki adaydı. Özellikle derin Android uzmanlığına sahip kuruluşlar için ilgi çekici bir seçenektir ancak kullanım durumumuz için nihayetinde yetersiz kaldı. Paylaşılan bir UI katmanının olmaması, olgunlukla ilgili sorular ve yürütme modelinin getirdiği ek yük, faydalarından ağır bastı.

Bu noktada, sonuç açıktı (temizle) ve ilk sezgimizle uyumluydu: istenen sonuca sürekli olarak yaklaşan tek mimari, kasıtlı olarak karıştırılmış bir yığındır. Her platformda Yerel UI – Android’de Jetpack Compose, iOS’ta SwiftUI – yüksek performanslı, düşük seviyeli bir dilde yazılmış paylaşılan bir iş mantığı katmanı tarafından desteklenir. Bu yaklaşımın bir geçmişi vardır: Dropbox, dilin operasyonel ve bilişsel maliyeti nedeniyle 2019’da terk etmeden önce mobil platformlarda iş mantığını paylaşmak için C++’ı meşhur bir şekilde kullanmıştır.

2023’ün sonunda Rust, sistem programlama dillerinin soyunda halef olarak açıkça ortaya çıkmıştı.

Rust, C++ ile aynı performans zarfını işgal eder, ancak tarihsel yükümlülüklerinin çoğu olmadan. Çöp toplama olmadan güçlü bellek güvenliği garantileri sağlar, derleme zamanında iş parçacığı güvenli eş zamanlılığı zorlar ve geniş, son derece yetkin bir açık kaynaklı ekosistem tarafından desteklenir. Aynı derecede önemli olan Rust, yerel mobil dillerle (iOS’ta Swift ve SwiftUI, Android’de Kotlin ve Jetpack Compose) temiz bir şekilde entegre olur ve bu da onu UI katmanından ödün vermeden temel mantığı paylaşmak için pragmatik bir seçim haline getirir.

Bu risksiz bir karar değildi. O zamanlar, Rust merkezli bir mimari üzerine inşa edilmiş büyük ölçekli, tüketiciye yönelik mobil uygulamaların çok az örneği vardı ve ekip içindeki Rust deneyimi sınırlıydı.

Ancak anlamlı inovasyon nadiren düşük riskli bölgelerde gerçekleşir. Asıl zorluk Rust’ın kendisi değil, örgütsel ataletti—kanıtlanmış, muhafazakar yaklaşımlardan net (açık) kısıtlamalar ve mühendislik yargısı tarafından yönlendirilen kasıtlı deneylere geçiş.

Yeni Proton Mail: sonuç ve öğrenimler

Bugüne hızlıca saralım ve kumarın nasıl sonuçlandığını görelim.

Aşağıdaki diyagram Mail mobil mimarisini temsil etmektedir. Rust çekirdeği, uygulamanın iş mantığının tamamından sorumludur. Rust kullanımını olağan uygulamalarının (ağ iletişimi, depolama alanı, algoritmik hesaplama) ötesine, karmaşık gezinme mantığının işlenmesine (ele alınmasına) kadar ittik. Buna bir örnek, ileti listesinin sonsuz kaydırmasını yöneten mantıktır. Alışılmışın dışında olsa da bu, kod yeniden kullanımını en üst düzeye çıkarma hedefimize ulaşmak için kilit önem taşıyordu. Sonuç olarak, kod tabanının neredeyse yüzde 80’i artık iOS ve Android arasında paylaşılıyor.

Bu, pazara sunma süresinin daha hızlı ve daha kaliteli olmasını sağladı mı? Nihai bir karar için henüz çok erken olsa da, ilk işaretler çok cesaret verici:

• Sürümün yayınlanmasını izleyen iki ay içinde ekip, her iki platformda da haftalık bir özellik güncellemesi temposunu korumayı başardı (toplam 12 özellik sürümü).
• Platformlar arasındaki özellik boşluklarını kapattık (kapalı), erteleme, takvim LCV ve bir sonraki iletiye kaydırma gibi uzun zamandır beklenen özellikleri Android’e getirdik.
• Bu erken aşamada bile, yeni kod tabanının her iki platformda da önceki nesillerden daha kararlı olduğu kanıtlandı: iOS çökme oranı yüzde 0,05 (yüzde 0,12’den düştü), Android’inki ise tarihsel bir taban çizgisine geri döndü (yüzde 0,19). Bu, Rust’ın çalışma zamanı kararlılığının güçlü bir onayıdır.

Destek de bu yaklaşım altında daha etkili bir şekilde ölçeklenir. İki bağımsız kod tabanına yayılmış biraz farklı mantık kusurlarından kaynaklanan yüzeysel olarak benzer sorunları takip etmektense, tek bir paylaşılan kök nedeni belirlemek ve çözmek genellikle daha hızlıdır. Uygulamanın çevrim dışı yeteneklerini destekleyen mantığı etkileyen bir kategori senkronizasyon sorunları sınıfını düzeltirken daha önce bir çalışma hipotezi olan şeyin deneysel onayını bulduk: tek bir kök neden, tek bir çözüm—sürüm 7.6.2 ile gönderilen (iletilen) Yeniden Tabanlama modülü tarafından yukarıdaki diyagramda temsil edilmektedir.

Madalyonun diğer yüzü?

• Hataların ve gerilemelerin daha geniş bir etkiye sahip olması ve her iki platformdaki kullanıcıları etkilemesi muhtemeldir. Gerçekten her şeye sahip olamazsınız—ancak uçtan uca (E2E) testlere aşırı indeksleme yaparak riski kesinlikle azaltabilirsiniz.
• Kullanıcıya yönelik bir çözümün yatay bir teknoloji ayrımı boyunca dilimlenmesinde olduğu gibi, bilgi siloları oluşturma ve uçtan uca kullanıcı deneyimlerine yönelik mühendislik odağını kaybetme riski vardır. Bunun farkında olmanız ve riski kasıtlı olarak azaltmanız gerekir. En etkili önlemler arasında:
  • Alt ekipleri teknoloji katmanları yerine özellikler sunacak (iletecek) şekilde hizalayın.
  • Mobil mühendislerini “tam yığın” olacak şekilde eğitin, yani hem Rust kod tabanında hem de yerel platformlarda hata ayıklayabilir, destekleyebilir ve mühendislik yapabilirler.

Mühendislik Dönüşümü için sırada ne var

Bu projenin en başından beri, risklerin Proton Mail’in çok ötesine uzandığı açıktı (temizle). Bu teknoloji yığınını Proton’un amiral gemisi uygulamasına başarıyla uygulamak, her zaman daha uzun bir yolculuğun ilk adımı olarak tasarlandı—bu yaklaşımın nihayetinde mobil ekosistemimizin geri kalanında da uygulanmasını görecek bir yolculuk.

Bu senaryo şimdi ortaya çıkıyor. Ben bu makaleyi yazarken, Hesap ve Ödeme SDK’larımız ve yeni nesil Proton Calendar mobil uygulamalarımız bu yeni teknik yöne uygun olarak yeniden yazılıyor.

Bu, ikinci bir mühendislik dönüşümü dalgasının başlangıcını işaret ediyor (işaretle)—bileşen yeniden kullanımını yalnızca platformlar arasında değil, aynı zamanda ürünler arasında da kolaylaştırmak için tasarlanmış bir mimari çerçeve ile teknoloji planını genişleten bir evrim. Bu geçiş bir gecede gerçekleşmeyecek olsa da, müşterilerimizin Proton’dan beklediği sorunsuz entegre edilmiş, gizlilik öncelikli ekosistemi oluşturmak için temeldir.

(1): Simon Lewis,“Birden fazla platformda uygulama uygulaması için bir strateji”, 2023.