Proton के नए Mail मोबाइल ऐप: दिखने से कहीं ज़्यादा कहानी है

पिछले साल सितंबर में हमने iOS और Android के लिए Proton Mail का एक बड़ा अपडेट लॉन्च किया।

ऊपर से देखने पे नए ऐप एक आधुनिक डिज़ाइन, बेहतर परफ़ॉर्मेंस और ऑफलाइन क्षमताएं देते हैं, लेकिन इनमें दिखने से कहीं ज़्यादा कहानी छिपी है। परदे के पीछे, ये ऐप Proton Mail को एक नई टेक्नोलॉजी स्टैक पे पूरी तरह से दोबारा लिखने का नतीजा हैं, एक प्रोजेक्ट जिसका इंटरनल नाम Engineering Transformation है। नोवेल शब्द का इस्तेमाल जानबूझकर किया गया है, क्योंकि — हमारी जानकारी तक — ये पहली बार है जब चुनी गई टेक्नोलॉजी को किसी स्थापित प्रोडक्शन एप्लीकेशन के संदर्भ में इस्तेमाल किया गया हो।

ये लेख हमारी टीम के इस क्रांति को अंजाम देने में गुज़रे रोमांचक सफ़र को उजागर करना चाहता है, और रास्ते में हमारी कम्युनिटी के पूछे गए कुछ सवालों के जवाब देना चाहता है। सबसे पहले, इसके पीछे का कारण हालात बदलने की ज़रूरत है।

शुरुआत कैसे हुई

ये एहसास कि चीज़ों को बदलने की ज़रूरत है, अक्टूबर 2023 के एक शुक्रवार की शाम को हुआ। ये हैरान करने वाली स्पष्टता के साथ सामने आया, लेकिन अचानक नहीं: ये महीनों की मेहनत का चरमोत्कर्ष था, जो Mail और Calendar मोबाइल प्रोडक्ट्स के साथ उपयोगकर्ताओं के अनुभव को प्रभावित करने वाली शुमार-असंबंधित समस्याओं के लिए एक समान आधार खोजने में लगा।

बहुत सरल बनाने के जोखिम के साथ, हम समस्याओं को तीन क्षेत्रों में संक्षेप में बता सकते हैं:

क्वालिटी: Mail iOS और Mail Android अलग-अलग देखे जाएं तो क्वालिटी और परफ़ॉर्मेंस के लिहाज़ से उम्मीदों पे खरे नहीं उतरते थे।
iOS और Android के बीच खासियतों का गैप: कुछ खासियतें सिर्फ एक प्लैटफॉर्म पे उपलब्ध थीं, और दूसरा प्लैटफॉर्म कब पकड़ बनाएगा इसकी कोई स्पष्टता नहीं थी।
इंजीनियरिंग की रफ़्तार: ज़रूरी अपडेट और बहुत समय से इंतज़ार वाली खासियतें दोनों प्लैटफॉर्म पे समय पर नहीं आ रही थीं।

कुछ समस्याएं मोबाइल से आगे तक थीं, और उनका जवाब देने के लिए टेक्नोलॉजी डोमेन से ऑर्गेनाइज़ेशनल स्केलिंग के रोमांचक समस्या क्षेत्र में, खासकर तेज़ी से बढ़ते टेक स्टार्टअप्स की ओर जाना पड़ता। लेकिन मोबाइल इकोसिस्टम की कमज़ोरी काफी हद तक टेक्नोलॉजी और आर्किटेक्चर में जड़ें रखती थी।

मोबाइल इंजीनियरिंग को स्केल करना

मोबाइल इंजीनियरिंग को स्केल करने में अनोखी चुनौतियों का सामना करना पड़ता है, जो backend और वेब टीमों को स्केल करने से काफी अलग हैं। ये अंतर प्लैटफॉर्म फ्रैगमेंटेशन और मोबाइल इकोसिस्टम की ऑपरेशनल हकीकतों से पैदा होते हैं। मोबाइल टीमों को आम तौर पर कई तरह के ऑपरेटिंग सिस्टम और डिवाइस (फोन, टैबलेट, कभी-कभी wearables) में कई प्लैटफॉर्म की सहायता करनी पड़ती है। iOS और Android अपनी प्रोग्रामिंग लैंग्वेज, फ्रेमवर्क और टूलिंग के साथ आते हैं, जिससे भारी दोहराव वाली मेहनत होती है: कई टीमें, दोहराए गए कोडबेस, और प्लैटफॉर्म-विशिष्ट और प्रोडक्ट-संबंधी काम के बीच लगातार समझौते। प्रोडक्ट की पेशकश को सिंक में रखने के लिए भारी कोऑर्डिनेशन चाहिए।

जो पूरी इंडस्ट्री के लिए चुनौती है, वो Proton के लिए खास तौर पर तीखी थी। Mail और Calendar जैसे फंक्शनलिटी ऐप बाज़ार के ज़्यादातर मोबाइल एप्लीकेशनों से स्वभावतः ज़्यादा जटिल हैं। ऊपर से शुरु-से-अंत तक एन्क्रिप्शन को हैंडल करने के लिए ज़रूरी क्लाइंट लॉजिक की अतिरिक्त परत मिला दें, तो खास तौर पर “मोटे” क्लाइंट बन जाते हैं। उस समय Android टीम Mail को बेहतर क्वालिटी स्टैंडर्ड्स में दोबारा लिखने में लगी थी — एक निवेश जिसमें 18 महीनों का ज़्यादातर हिस्सा लग गया। iOS को भी नए सिरे से आर्किटेक्ट करने की बहुत ज़रूरत थी, Calendar का तो ज़िक्र ही क्या। दोहराव की कीमत हमारे सारे इंजीनियरिंग रिसोर्सेज़ को खा रही थी, और ये साफ था कि वैसे ही करते रहने से हम सफल नहीं होने वाले थे।

अपने फंसे होने को पहचानने की सबसे अच्छी बात ये है कि ये अपने मौजूदा हालात की सीमाओं से बाहर सोचने के लिए मजबूर करने वाला फैक्टर बन जाता है। अगर हम उन पसंदों और वादों के बोझ से मुक्त होकर, जिन्होंने हमें यहां तक लाया, नए सिरे से शुरू कर सकते, तो क्या करते? जब पिछले दशक में सफल कंपनियों ने इस समस्या से कैसे निपटा, इस पे करीब से नज़र डालें, तो महसूस होता है कि उन्होंने सिर्फ दो संभव रणनीतियों में से एक अपनाई:

1. उन्होंने समस्या पे पैसा लुटाया, लगातार बड़ी टीमें बनाते हुए, क्योंकि ऊंची ऑपरेशनल लागतों को अथाह निवेश और/या शानदार रिटर्न के संयोजन से पूरा किया जाता था। ये Proton के VC-मुक्त बिज़नेस मॉडल के लिए कोई विकल्प नहीं था: हम विज्ञापन-आधारित, निवेशक-समर्थित प्रतिस्पर्धियों की खर्च क्षमता से मुकाबला नहीं कर सकते।
2. उन्होंने बेकार खर्चे से छुटकारा पाने के लिए अपने ऐप को नए सिरे से इंजीनियर किया, यानी (जितना संभव हो) एक शेयर किए गए कोडबेस का इस्तेमाल करके ऐप बनाना।

विकल्प 1 काम न आने के कारण, आगे का रास्ता तय था।

एक मकसद तक पहुंचने का साधन: सही टेक स्टैक चुनना

अगला कदम था ऐसा टेक स्टैक चुनना जो वाकई काम कर सके।

पिछले 15 सालों में क्रॉस-प्लैटफॉर्म मोबाइल डेवलपमेंट “सबके लिए एक” समाधानों से भर गया है: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform, और कई और। हर एक उसी वादे के साथ आया — नेटिव डेवलपमेंट को पूरी तरह बदल देना। व्यवहार में, ज़्यादातर या तो पूरी तरह असफल हुए या सिर्फ कड़ी सीमाओं वाले समस्या क्षेत्रों के भीतर सफल हुए। कोई सार्वभौमिक एब्स्ट्रैक्शन नहीं है जो प्लैटफॉर्म के अंतरों को मिटा दे: जिसने बड़े मोबाइल एप्लीकेशन शिप और मेंटेन किए हैं, वो ये जानता है। आगे बढ़ने का इकलौता भरोसेमंद तरीका है टूलिंग ट्रेंड्स से आगे की बजाय ठोस ज़रूरतों से पीछे की ओर काम करना।

हमने उस अंतिम लक्ष्य को गैर-समझौतावादी ज़रूरतों (1) के एक सेट में बदला जो कोई भी चुना गया समाधान पूरा करे, और पूरे मूल्यांकन प्रक्रिया में उन्हें अपने मार्गदर्शक फ्रेमवर्क के रूप में इस्तेमाल किया:

1. लागत और समय-सीमा: स्टैक को iOS और Android में Proton Mail को शिप करने, मेंटेन करने और विकसित करने के लिए ज़रूरी लागत और समय में काफी कमी लानी थी।
2. उपयोगकर्ता अनुभव: इसे नेटिव के करीब परफ़ॉर्मेंस और इंटरैक्शन क्वालिटी बनाए रखनी थी — उससे कम कुछ भी स्वीकार नहीं था।
3. रणनीतिक दीर्घकालिक सुरक्षा: समाधान लंबे समय तक चलने वाला होना चाहिए था। हम ऐसे तीसरें-पार्टी फ्रेमवर्क से बचने के लिए सचेत थे जो हमारे रोडमैप को किसी दूसरे वेंडर की निरंतर सहायता पे निर्भर बना देते।

पहली दो सीमाओं के बीच का तनाव इंडस्ट्री के हिसाब से हॉली ग्रेल है: “एक क्रॉस-प्लैटफॉर्म समाधान जो नेटिव एप्लीकेशनों की परफ़ॉर्मेंस और उपयोगकर्ता अनुभव देता है।”

शुरू से ही हमें शक था कि React Native या Flutter — उस समय के दो प्रमुख क्रॉस-प्लैटफॉर्म फ्रेमवर्क — ये स्तर पूरा कर सकते हैं। फिर भी, हमने Mail के संदेश सूची व्यू के प्रूफ-ऑफ-कॉन्सेप्ट इंप्लीमेंटेशन बनाकर उस शक की पुष्टि की।

React Native ने जल्दी ही अपनी सीमाएं दिखा दीं। एक बड़े डेटासेट में स्क्रॉल करने से उसके इंटरप्रेटेड एग्जीक्यूशन मॉडल की कीमत दर्दनाक तरीके से साफ दिख गई। Flutter बेहतर चला, लेकिन UI खुलकर नॉन-नेटिव लगता रहा, खासकर iOS पे। ज़्यादा ज़रूरी ये है कि Flutter Google के नियंत्रित एक प्रोप्राइटरी फ्रेमवर्क है, जिसका इन-हाउस टेक्नोलॉजीज़ को छोड़ देने का इतिहास(नई विंडो) रहा है और हाल ही में Flutter टीम के बड़े हिस्से को निकाल दिया था। दीर्घकालिक सुरक्षा और भरोसेमंदी की गारंटी वाले प्रोडक्ट के लिए इस स्तर की बाहरी निर्भरता स्वीकार्य नहीं थी।

Kotlin Multiplatform अगला उम्मीदवार था। ये एक आकर्षक विकल्प है — खासकर गहरी Android एक्सपर्टीज़ वाले संगठनों के लिए — लेकिन आखिरकार ये हमारे इस्तेमाल के मामले के लिए कम पड़ गया। शेयर की गई UI लेयर की अनुपस्थिति, परिपक्वता को लेकर सवाल, और इसके एग्जीक्यूशन मॉडल से आई अतिरिक्त जटिलता ने इसके फायदों से भारी पड़ गई।

इस बिंदु पे, निष्कर्ष साफ था और हमारी शुरुआती अंतर्दृष्टि से मेल खाता था: इकलौता आर्किटेक्चर जो लगातार मनचाहे नतीजे के करीब पहुंचता है, वो जानबूझकर मिला-जुला स्टैक है। हर प्लैटफॉर्म पे नेटिव UI — Android पे Jetpack Compose, iOS पे SwiftUI — जो एक हाई-परफ़ॉर्मेंस, लो-लेवल लैंग्वेज में लिखी शेयर की गई बिज़नेस-लॉजिक लेयर पे टिका है। इस तरीके का इतिहास रहा है: Dropbox 2019 में उस लैंग्वेज की ऑपरेशनल और कॉग्निटिव लागत की वजह से इसे छोड़ने से पहले मोबाइल प्लैटफॉर्म में बिज़नेस लॉजिक शेयर करने के लिए C++ का इस्तेमाल करने में मशहूर था।

2023 के आखिर तक, Rust सिस्टम प्रोग्रामिंग लैंग्वेजेज़ की वंशावली में उत्तराधिकारी के रूप में साफ तौर पर सामने आ चुका था।

Rust C++ जितना ही परफ़ॉर्मेंस दायरा रखता है, लेकिन उसकी कई ऐतिहासिक कमज़ोरियों के बिना। ये गार्बेज कलेक्शन के बिना मजबूत मेमोरी सेफ्टी गारंटी देता है, कंपाइल समय पे थ्रेड-सेफ कंकरेंसी लागू करता है, और एक बड़े, अत्यंत सक्षम ओपन-सोर्स इकोसिस्टम की सहायता से समर्थित है। उतना ही ज़रूरी, Rust नेटिव मोबाइल लैंग्वेजेज़ के साथ साफ तौर पर इंटीग्रेट होता है — iOS पे Swift और SwiftUI, Android पे Kotlin और Jetpack Compose — जिससे बिना UI लेयर में छेड़छाड़ किए कोर लॉजिक शेयर करने के लिए ये व्यावहारिक पसंद बनता है।

ये कोई जोखिम-मुक्त फैसला नहीं था। उस समय, Rust-केंद्रित आर्किटेक्चर पे बने बड़े पैमाने के, कंज्यूमर-सामने वाले मोबाइल एप्लीकेशनों के थोड़े ही उदाहरण थे, और टीम के भीतर Rust का अनुभव सीमित था।

लेकिन सार्थक इनोवेशन शायद ही कभी कम-जोखिम वाले इलाके में होता है। असली चुनौती Rust खुद नहीं थी, बल्कि संगठनात्मक जड़ता थी — साबित, रूढ़िवादी तरीकों से जानबूझकर प्रयोग की ओर बढ़ना, स्पष्ट सीमाओं और इंजीनियरिंग समझ के मार्गदर्शन में।

नया Proton Mail: नतीजे और सीख

आइए वक्त को आज तक आगे बढ़ाएं और देखें कि ये जोखिम भरा दांव कैसा निकला।

नीचे दिया गया डायग्राम Mail मोबाइल का आर्किटेक्चर दिखाता है। Rust कोर एप्लीकेशन के पूरे बिज़नेस लॉजिक के लिए ज़िम्मेदार है। हमने Rust के इस्तेमाल को उसके आम उपयोगों (नेटवर्किंग, स्टोरेज, एल्गोरिदमिक कंप्यूटेशन) से आगे बढ़ाकर जटिल नेविगेशन लॉजिक को संभालने तक ले जाया। इसकी एक मिसाल है संदेश सूची के इनफिनिट स्क्रॉलिंग को नियंत्रित करने वाला लॉजिक। गैर-पारंपरिक होते हुए भी, ये कोड रीयूज़ को सबसे बड़ा करने के हमारे लक्ष्य को हासिल करने के लिए निर्णायक साबित हुआ। नतीजतन, लगभग 80% कोडबेस अब iOS और Android में शेयर किया जाता है।

क्या इसका असर तेज़, बेहतर क्वालिटी वाले टाइम-टू-मार्केट में दिखा? अंतिम फैसले के लिए अभी बहुत जल्दी है, लेकिन शुरुआती संकेत बहुत उत्साहजनक रहे हैं:

• रिलीज़ के बाद के दो महीनों में टीम दोनों प्लैटफॉर्म में खासियत अपडेट की साप्ताहिक लय बनाए रखने में सफल रही (कुल 12 खासियत रिलीज़)।
• हमने प्लैटफॉर्मों के बीच खासियतों के गैप बंद कर दिए, और Android में बहुत समय से इंतज़ार वाली खासियतें लाए, जैसे सूचना बंद, कैलेंडर RSVP, और अगले संदेश पे स्वाइप।
• इस शुरुआती चरण में भी, नया कोडबेस दोनों प्लैटफॉर्म पे पिछली पीढ़ियों से ज़्यादा स्थिर साबित हुआ है: iOS की क्रैश दर 0.05% है (0.12% से नीचे), जबकि Android की वापस ऐतिहासिक बेसलाइन (0.19%) पे है। ये Rust की रनटाइम स्थिरता की मजबूत मुहर है।

इस तरीके में सहायता भी ज़्यादा प्रभावी तरीके से स्केल होती है। दो अलग-अलग कोडबेस में फैली थोड़ी अलग लॉजिक खामियों से पैदा हुई ऊपर से मिलती-जुलती समस्याओं के पीछे भागने की बजाय एक शेयर किए गए मूल कारण को पहचानना और सुलझाना अक्सर तेज़ होता है। ऐप की ऑफलाइन क्षमताओं को आधार देने वाले लॉजिक को प्रभावित करने वाली कैटेगरी सिंक्रोनाइज़ेशन समस्याओं की एक श्रेणी ठीक करते वक्त हमें पहले से चल रही परिकल्पना की व्यावहारिक पुष्टि मिली: एक मूल कारण, एक समाधान — ऊपर के डायग्राम में वर्ज़न 7.6.2 के साथ आए Rebasing मॉड्यूल से दर्शाया गया।

सिक्के का दूसरा पहलू?

• बग और रिग्रेशन का असर ज़्यादा व्यापक होने और दोनों प्लैटफॉर्म पे उपयोगकर्ताओं को प्रभावित करने की संभावना रहती है। सब कुछ एक साथ नहीं मिल सकता — लेकिन शुरु-से-अंत तक (E2E) टेस्टिंग पे ज़्यादा ज़ोर देकर जोखिम को ज़रूर कम किया जा सकता है।
• किसी भी उपयोगकर्ता-सामने वाले समाधान को क्षैतिज टेक्नोलॉजी विभाजन के साथ काटने की तरह, ज्ञान सिलोज़ बनाने और शुरु-से-अंत तक के उपयोगकर्ता अनुभवों पे कुछ इंजीनियरिंग फोकस खोने का जोखिम रहता है। आपको इसका ध्यान रखना चाहिए और जानबूझकर जोखिम कम करना चाहिए। सबसे प्रभावी उपायों में:
  • टेक्नोलॉजी लेयरों की बजाय खासियतें पहुंचाने के लिए सब-टीमों को संरेखित करें।
  • मोबाइल इंजीनियरों को “फुल स्टैक” बनने के लिए तैयार करें, यानी Rust कोडबेस और नेटिव प्लैटफॉर्म दोनों में डीबग, सहायता और इंजीनियरिंग करने में सक्षम.

Engineering Transformation के लिए आगे क्या

इस प्रोजेक्ट की शुरुआत से ही ये साफ था कि दांव Proton Mail से कहीं आगे तक था। इस टेक्नोलॉजी स्टैक को Proton के फ्लैगशिप एप्लीकेशन पे सफलतापूर्वक लागू करना हमेशा एक लंबे सफ़र का पहला कदम माना गया था — एक सफ़र जो आखिरकार इस तरीके को हमारे बाकी मोबाइल इकोसिस्टम में फैलाने तक जाएगा।

वो दृश्य अब सामने आ रहा है। जिस वक्त ये लेख लिखा जा रहा है, हमारे Account और Payment SDK, साथ ही Proton Calendar मोबाइल ऐप की अगली पीढ़ी, इस नई टेक्निकल दिशा के मुताबिक दोबारा लिखी जा रही हैं।

ये इंजीनियरिंग ट्रांसफॉर्मेशन की दूसरी लहर की शुरुआत को मार्क करता है — एक विकास जो टेक्नोलॉजी ब्लूप्रिंट को एक आर्किटेक्चरल फ्रेमवर्क के साथ विस्तारित करता है, जो कंपोनेंट रीयूज़ को आसान बनाने के लिए डिज़ाइन किया गया है, न सिर्फ प्लैटफॉर्म में बल्कि प्रोडक्ट्स में भी। ये बदलाव एक रात में नहीं होगा, लेकिन सहज तरीके से इंटीग्रेटेड, प्राइवेसी-फर्स्ट इकोसिस्टम बनाने के लिए ये बुनियादी है जिसकी हमारे ग्राहकों को Proton से उम्मीद है।

(1): Simon Lewis,“एक से ज़्यादा प्लैटफॉर्म पे एप्लीकेशन इंप्लीमेंटेशन की रणनीति”, 2023।