हर जगह के लिए अच्छे नोट

पिछले दो सालों से, Goodnotes की इंजीनियरिंग टीम, iPad नोट लेने वाले इस ऐप्लिकेशन को दूसरे प्लैटफ़ॉर्म पर लाने के लिए एक प्रोजेक्ट पर काम कर रही है. इस केस स्टडी में बताया गया है कि साल 2022 के iPad ऐप्लिकेशन को किस तरह वेब टेक्नोलॉजी की मदद से वेब, ChromeOS, Android, और Windows पर ऐक्सेस किया गया. साथ ही, WebAssembly उस स्विफ़्ट कोड का फिर से इस्तेमाल कर रहा है जिस पर टीम दस साल से भी ज़्यादा समय से काम कर रही है.

Pedro Gómez

Thomas Steiner

Goodnotes अब वेब, Android, और Windows पर क्यों उपलब्ध है

साल 2021 में, Goodnotes सिर्फ़ iOS और iPad के लिए एक ऐप्लिकेशन के तौर पर उपलब्ध था. Goodnotes की इंजीनियरिंग टीम ने एक बड़ी तकनीकी चुनौती स्वीकार की: Goodnotes का नया वर्शन बनाना, लेकिन दूसरे ऑपरेटिंग सिस्टम और प्लैटफ़ॉर्म के लिए. प्रॉडक्ट, iOS ऐप्लिकेशन के साथ पूरी तरह से काम करना चाहिए. साथ ही, वह उन नोट को रेंडर करना चाहिए जो iOS ऐप्लिकेशन के साथ काम करते हैं. PDF या अटैच की गई किसी भी इमेज के ऊपर दिया गया कोई भी नोट या इमेज अटैच होनी चाहिए. साथ ही, उसमें वही स्ट्रोक होने चाहिए जो iOS ऐप्लिकेशन पर दिखाया गया हो. जोड़ा गया कोई भी स्ट्रोक, उस स्ट्रोक के बराबर होना चाहिए जिसे iOS उपयोगकर्ता बना सकते हैं. यह टूल उपयोगकर्ता के इस्तेमाल किए जा रहे टूल से अलग होना चाहिए. उदाहरण के लिए, पेन, हाइलाइटर, फ़ाउंटेन पेन, शेप या इरेज़र.

ज़रूरी शर्तों और इंजीनियरिंग टीम के अनुभव के आधार पर, टीम ने जल्द ही यह नतीजा निकाला कि Swift कोड बेस का फिर से इस्तेमाल करना सबसे अच्छा रहेगा. ऐसा इसलिए, क्योंकि यह कई सालों से लिखा जा चुका है और अच्छी तरह से जांचा जा चुका है. हालाँकि, क्या न सिर्फ़ पहले से मौजूद iOS/iPad ऐप्लिकेशन को किसी दूसरे प्लैटफ़ॉर्म या Flutter या Compose मल्टीप्लैटफ़ॉर्म जैसी टेक्नोलॉजी पर पोर्ट करना चाहिए? नए प्लैटफ़ॉर्म पर जाने के लिए, आपको Goodnotes को फिर से लिखना होगा. ऐसा करने से हो सकता है कि पहले से लागू किए गए iOS ऐप्लिकेशन और एक भी नए ऐप्लिकेशन के बीच डेवलपमेंट की रेस शुरू हो जाए या नए कोड बेस के अपडेट होने पर मौजूदा ऐप्लिकेशन पर नया डेवलपमेंट बंद हो जाए. अगर Goodnotes, Swift कोड का फिर से इस्तेमाल कर सके, तो क्रॉस-प्लैटफ़ॉर्म टीम, ऐप्लिकेशन की बुनियादी बातों पर काम कर रही थी. साथ ही, उस समय iOS टीम की नई सुविधाओं का इस्तेमाल करने और सुविधाओं की समानता पर काम किया जा रहा था.

इस प्रॉडक्ट ने iOS के लिए कई दिलचस्प चुनौतियों को पहले ही हल कर लिया है, जिनका इस्तेमाल इन सुविधाओं को जोड़ने के लिए किया गया है:

• नोट रेंडरिंग.
• दस्तावेज़ और नोट सिंक होना.
• कॉन्फ़्लिक्ट-फ़्री रैप्लिकेटेड डेटा टाइप का इस्तेमाल करके नोट से जुड़ी समस्याओं का समाधान.
• एआई (AI) मॉडल के इवैलुएशन के लिए डेटा का विश्लेषण.
• कॉन्टेंट खोजना और दस्तावेज़ को इंडेक्स करना.
• पसंद के मुताबिक स्क्रोल करने का अनुभव और ऐनिमेशन.
• सभी यूज़र इंटरफ़ेस (यूआई) लेयर के लिए, मॉडल लागू करने की प्रक्रिया देखें.

दूसरे प्लैटफ़ॉर्म के लिए इन सभी को लागू करना काफ़ी आसान होगा, अगर इंजीनियरिंग टीम को iOS और iPad ऐप्लिकेशन के लिए पहले से काम कर रहे iOS कोडबेस मिल पाएं और इन्हें एक प्रोजेक्ट के हिस्से के तौर पर लागू कर सकें. Goodnotes को Windows, Android या वेब ऐप्लिकेशन के तौर पर शिप किया जा सकता है.

Goodnotes का तकनीकी स्टैक

अच्छी बात यह है कि वेब पर मौजूदा Swift कोड को फिर से इस्तेमाल करने का एक तरीका WebAssembly (Wasm) है. Goodnotes ने ओपन सोर्स और समुदाय की मदद से बनाए गए प्रोजेक्ट SwiftWasm के साथ Wasm का इस्तेमाल करके एक प्रोटोटाइप बनाया है. SwiftWasm के साथ Goodnotes की टीम पहले से लागू किए गए सभी Swift कोड का इस्तेमाल करके Wasm बाइनरी जनरेट कर सकती है. इस बाइनरी को Android, Windows, ChromeOS, और दूसरे सभी ऑपरेटिंग सिस्टम के लिए, प्रोग्रेसिव वेब ऐप्लिकेशन के तौर पर शिप किए गए वेब पेज में शामिल किया जा सकता है.

इसका मकसद Goodnotes को PWA के तौर पर रिलीज़ करना था और इसे हर प्लैटफ़ॉर्म के स्टोर पर लिस्ट करना था. Swift के अलावा, iOS के लिए पहले से इस्तेमाल की जा रही प्रोग्रामिंग भाषा और वेब पर Swift कोड चलाने के लिए इस्तेमाल की जाने वाली WebAssembly, इस प्रोजेक्ट में इन टेक्नोलॉजी का इस्तेमाल किया गया:

• TypeScript: वेब टेक्नोलॉजी के लिए, सबसे ज़्यादा इस्तेमाल की जाने वाली प्रोग्रामिंग भाषा.
• प्रतिक्रिया और वेबपैक: यह वेब का सबसे लोकप्रिय फ़्रेमवर्क और बंडलर होता है.
• PWA और सर्विस वर्कर: इस प्रोजेक्ट के लिए चालू करने वाले बड़े लोग: इसकी वजह यह है कि टीम हमारे ऐप्लिकेशन को किसी ऐसे ऑफ़लाइन ऐप्लिकेशन के तौर पर शिप कर सकती है जो किसी भी अन्य iOS ऐप्लिकेशन की तरह काम करता हो. साथ ही, इसे स्टोर या ब्राउज़र से इंस्टॉल किया जा सकता है.
• PWABuilder: Goodnotes मुख्य प्रोजेक्ट का इस्तेमाल, PWA को नेटिव Windows बाइनरी में रैप करने के लिए किया जाता है, ताकि टीम हमारे ऐप्लिकेशन को Microsoft Store से उपलब्ध करा सके.
• भरोसेमंद वेब गतिविधियां: यह Android की सबसे अहम टेक्नोलॉजी है. इसका इस्तेमाल कंपनी, अपने PWA को नेटिव ऐप्लिकेशन के तौर पर करने के लिए करती है.

नीचे दिए गए डायग्राम में दिखाया गया है कि क्लासिक TypeScript और React का इस्तेमाल करके क्या लागू किया जाता है. साथ ही, SwiftWasm और वनीला JavaScript, Swift, और WebAssembly का इस्तेमाल करके क्या लागू किया जाता है. प्रोजेक्ट का यह हिस्सा JSKit इस्तेमाल किया जाता है. यह Swift और WebAssembly के लिए एक JavaScript इंटरऑपरेबिलिटी लाइब्रेरी है. इसका इस्तेमाल, ज़रूरत पड़ने पर हमारे Swift कोड से हमारी एडिटर स्क्रीन में DOM को मैनेज करने के लिए किया जाता है. इसके अलावा, यह ब्राउज़र के हिसाब से बने कुछ एपीआई का भी इस्तेमाल करती है.

Wasm और वेब का इस्तेमाल क्यों करना चाहिए?

हालांकि, Wasm को Apple ने आधिकारिक तौर पर मंज़ूरी नहीं दी है, लेकिन Goodnotes की इंजीनियरिंग टीम के मुताबिक, इसकी ये वजहें हो सकती हैं:

• कोड की 1,00,000 से ज़्यादा लाइनों का फिर से इस्तेमाल.
• क्रॉस-प्लैटफ़ॉर्म ऐप्लिकेशन में योगदान देने के साथ-साथ, मुख्य प्रॉडक्ट का डेवलपमेंट जारी रखने की क्षमता.
• बार-बार डेवलप करने की प्रोसेस का इस्तेमाल करके, हर प्लैटफ़ॉर्म पर जल्द से जल्द पहुंचने की क्षमता.
• सभी कारोबारी लॉजिक को डुप्लीकेट किए बिना एक ही दस्तावेज़ को रेंडर करने का कंट्रोल और हमारे लागू करने के तरीकों में अंतर पेश करना.
• परफ़ॉर्मेंस को बेहतर बनाने के लिए, हर प्लैटफ़ॉर्म पर एक ही समय में किए गए सभी सुधारों का फ़ायदा उठाना. साथ ही, हर प्लैटफ़ॉर्म पर लागू की गई सभी गड़बड़ियों को ठीक करना.

कोड की 1,00,000 से ज़्यादा लाइनों का फिर से इस्तेमाल करना और हमारी रेंडरिंग पाइपलाइन को लागू करने का कारोबारी नियम बहुत अहम था. साथ ही, अगर Swift कोड को दूसरे टूलचेन के साथ काम करता है, तो वे आने वाले समय में ज़रूरत पड़ने पर इस कोड को अलग-अलग प्लैटफ़ॉर्म पर फिर से इस्तेमाल कर सकते हैं.

बार-बार किया जाने वाला प्रॉडक्ट डेवलपमेंट

उपयोगकर्ताओं तक जल्द से जल्द कुछ उपलब्ध कराने के लिए, टीम ने बार-बार एक ही तरीका अपनाया. Goodnote की शुरुआत प्रॉडक्ट के रीड-ओनली वर्शन से हुई है जहां उपयोगकर्ता शेयर किया गया दस्तावेज़ ले सकते हैं और उसे किसी भी प्लैटफ़ॉर्म से पढ़ सकते हैं. लिंक का इस्तेमाल करके वे उसी नोट को ऐक्सेस कर पाएंगे और पढ़ पाएंगे जिसे उन्होंने अपने iPad से लिखा था. अगला चरण बदलाव करने की सुविधाओं में जोड़ा गया, ताकि क्रॉस-प्लैटफ़ॉर्म वर्शन को iOS वर्शन जैसा बनाया जा सके.

रीड-ओनली प्रॉडक्ट के पहले वर्शन को तैयार होने में छह महीने लगे. उसके बाद के नौ महीने, एडिटिंग की पहली सुविधाओं और यूज़र इंटरफ़ेस (यूआई) स्क्रीन के लिए थे, जहां वे सभी दस्तावेज़ देखे जा सकते हैं जो आपने बनाए हैं या किसी ने आपके साथ शेयर किए हैं. इसके अलावा, SwiftWasm Toolchain की मदद से iOS प्लैटफ़ॉर्म की नई सुविधाओं को क्रॉस-प्लैटफ़ॉर्म प्रोजेक्ट में आसानी से पोर्ट किया जा सका. उदाहरण के लिए, कोड की हज़ारों लाइनों का फिर से इस्तेमाल करके, एक नए तरह का पेन बनाया और क्रॉस-प्लैटफ़ॉर्म पर आसानी से लागू किया जा सकता है.

इस प्रोजेक्ट को बनाना एक शानदार अनुभव था और Goodnotes ने इससे बहुत कुछ सीखा है. इसलिए, नीचे दिए गए सेक्शन में वेब डेवलपमेंट और WebAssembly और Swift जैसी भाषाओं के इस्तेमाल से जुड़े दिलचस्प तकनीकी पहलुओं पर फ़ोकस किया गया है.

शुरुआती रुकावटें

कई अलग-अलग नज़रियों से इस प्रोजेक्ट पर काम करना बहुत चुनौती भरा काम था. टीम को मिली पहली रुकावट, SwiftWasm टूलचेन से जुड़ी थी. टूलचेन से टीम को बहुत मदद मिली, लेकिन सभी iOS कोड Wasm के साथ काम नहीं करते. उदाहरण के लिए, IO या यूज़र इंटरफ़ेस (यूआई) से जुड़ा कोड, जैसे कि व्यू को लागू करना, एपीआई क्लाइंट या डेटाबेस के ऐक्सेस का फिर से इस्तेमाल नहीं किया जा सकता था. इसलिए, टीम को ऐप्लिकेशन के खास हिस्सों की रीफ़ैक्टरिंग शुरू करनी थी, ताकि वे क्रॉस-प्लैटफ़ॉर्म सलूशन से फिर से इस्तेमाल कर सकें. टीम ने जो पीआर बनाई, उनमें से ज़्यादातर डिपेंडेंसी को रीफ़ैक्टर किया गया, ताकि टीम बाद में डिपेंडेंसी इंजेक्शन या दूसरी मिलती-जुलती रणनीतियों का इस्तेमाल करके उन्हें बदल सके. iOS कोड में मूल रूप से रॉ बिज़नेस लॉजिक मिला था, जिसे Wasm में लागू किया जा सकता था. इसे इनपुट/आउटपुट और यूज़र इंटरफ़ेस के लिए ज़िम्मेदार कोड के साथ लागू किया जा सकता था, जिसे Wasm में लागू नहीं किया जा सका, क्योंकि Wasm में भी यह काम नहीं करता. इसलिए, जब Swift बिज़नेस लॉजिक, प्लैटफ़ॉर्म के बीच फिर से इस्तेमाल किए जाने के लिए तैयार हो गया, तब TypeScript में IO और यूज़र इंटरफ़ेस (यूआई) कोड को फिर से लागू करना ज़रूरी था.

परफ़ॉर्मेंस से जुड़े सवाल हल किए गए

जब Goodnotes ने एडिटर पर काम करना शुरू किया, तब टीम को बदलाव करने के अनुभव से जुड़ी कुछ समस्याओं का पता चला. साथ ही, टेक्नोलॉजी से जुड़ी चुनौतियों की वजह से हम अपने रोडमैप पर काम करने लगे. पहली समस्या परफ़ॉर्मेंस से जुड़ी थी. JavaScript एक सिंगल-थ्रेड वाली भाषा है. इसका मतलब है कि इसमें एक कॉल स्टैक और एक मेमोरी हीप है. यह कोड को क्रम से चलाता है और अगले पर जाने से पहले किसी कोड का एक्ज़ीक्यूशन पूरा करना होता है. यह सिंक्रोनस है, लेकिन कभी-कभी यह नुकसान पहुंचा सकता है. उदाहरण के लिए, अगर किसी फ़ंक्शन को एक्ज़ीक्यूट होने में समय लगता है या किसी चीज़ के लिए इंतज़ार करना पड़ता है, तो इस बीच सभी चीज़ें फ़्रीज़ हो जाती हैं. और इंजीनियर को यही हल करना था. हमारे कोडबेस में रेंडरिंग लेयर या दूसरे जटिल एल्गोरिदम से जुड़े कुछ खास पाथ का मूल्यांकन करना टीम के लिए मुश्किल था, क्योंकि ये एल्गोरिदम सिंक्रोनस थे और उन्हें एक्ज़ीक्यूट करने से मुख्य थ्रेड काम नहीं कर रहा था. Goodnotes की टीम ने इन्हें तेज़ी से काम करने के लिए फिर से लिखा और इनमें से कुछ को रीफ़ैक्टर किया, ताकि ये एसिंक्रोनस बन सकें. उन्होंने एक यील्ड रणनीति भी पेश की, ताकि ऐप्लिकेशन एल्गोरिदम को एक्ज़ीक्यूशन से रोक सके और उसे बाद में जारी रख सके. इससे ब्राउज़र यूज़र इंटरफ़ेस (यूआई) अपडेट कर पाता है और फ़्रेम छूटने से बचता है. यह iOS ऐप्लिकेशन के लिए समस्या नहीं थी, क्योंकि मुख्य iOS थ्रेड यूज़र इंटरफ़ेस को अपडेट करते समय, थ्रेड का इस्तेमाल कर सकता है और बैकग्राउंड में इन एल्गोरिदम का आकलन कर सकता है.

एक अन्य समाधान जिसे इंजीनियरिंग टीम को हल करना था वह था DOM में अटैच किए गए एचटीएमएल एलिमेंट पर आधारित यूज़र इंटरफ़ेस (यूआई) को, फ़ुल-स्क्रीन कैनवस पर आधारित दस्तावेज़ के यूज़र इंटरफ़ेस (यूआई) में माइग्रेट करना. इस प्रोजेक्ट में किसी भी दूसरे वेब पेज की तरह, एचटीएमएल एलिमेंट का इस्तेमाल करके, डीओएम स्ट्रक्चर के हिस्से के तौर पर किसी दस्तावेज़ से जुड़े नोट और कॉन्टेंट दिखाना शुरू किया गया. हालांकि, कुछ समय के लिए, लो-एंड डिवाइस पर परफ़ॉर्मेंस को बेहतर बनाने के लिए फ़ुल-स्क्रीन कैनवस पर माइग्रेट कर दिया गया. इससे ब्राउज़र के DOM अपडेट पर काम करने का समय कम हो गया.

इंजीनियरिंग टीम ने इन बदलावों की पहचान उन चीज़ों के तौर पर की है जिनकी वजह से शायद कुछ समस्याएं हल हो सकती हैं और अगर उन्होंने प्रोजेक्ट की शुरुआत में ये बदलाव किए थे.

• ज़्यादा एल्गोरिदम के लिए, बार-बार वेब वर्कर का इस्तेमाल करके मुख्य थ्रेड को ज़्यादा से ज़्यादा ऑफ़लोड करें.
• शुरुआत से ही JS-Swift इंटरऑप लाइब्रेरी के बजाय, एक्सपोर्ट किए गए और इंपोर्ट किए गए फ़ंक्शन का इस्तेमाल करें, ताकि Wasm के कॉन्टेक्स्ट से परफ़ॉर्मेंस पर पड़ने वाले असर को कम किया जा सके. यह JavaScript इंटरऑप लाइब्रेरी से डीओएम या ब्राउज़र का ऐक्सेस पाने में मदद मिलती है. हालांकि, यह नेटिव Wasm के एक्सपोर्ट किए गए फ़ंक्शन से धीमी है.
• पक्का करें कि कोड, हुड के तहत OffscreenCanvas का इस्तेमाल करने की अनुमति देता हो, ताकि ऐप्लिकेशन मुख्य थ्रेड को ऑफ़लोड कर सके और Canvas API के सभी इस्तेमाल को वेब वर्कर पर ले जा सके. इससे ऐप्लिकेशन की परफ़ॉर्मेंस बेहतर होगी.
• Wasm से जुड़े सभी एक्ज़ीक्यूशन को किसी वेब वर्कर या वेब वर्कर के एक पूल पर भी ले जाएं, ताकि ऐप्लिकेशन मुख्य थ्रेड का वर्कलोड कम कर सके.

टेक्स्ट एडिटर

एक और दिलचस्प समस्या एक खास टूल, टेक्स्ट एडिटर से जुड़ी थी. इस टूल को iOS पर लागू करना NSAttributedString पर आधारित है. यह एक छोटा टूलसेट है, जिसमें RTF का इस्तेमाल किया जाता है. हालांकि, यह SwiftWasm के साथ काम नहीं करता. इसलिए, क्रॉस-प्लैटफ़ॉर्म टीम को पहले आरटीएफ़ व्याकरण के आधार पर कस्टम पार्सर बनाना पड़ा. बाद में, आरटीएफ़ को एचटीएमएल में और बाद में बदलाव करने के अनुभव को आरटीएफ़ ग्रामर में बदलकर बदलाव करने की प्रोसेस लागू की गई. इसी दौरान, iOS की टीम ने इस टूल को लागू करने के नए तरीके पर काम करना शुरू कर दिया. यह टूल RTF के इस्तेमाल को एक कस्टम मॉडल से बदल देता है, ताकि एक ही स्विफ़्ट कोड शेयर करने वाले सभी प्लैटफ़ॉर्म पर, ऐप्लिकेशन सही तरीके से स्टाइल वाला टेक्स्ट दिखा सके.

यह चुनौती, प्रोजेक्ट के रोडमैप में सबसे दिलचस्प थी, क्योंकि इसे लोगों की ज़रूरतों के हिसाब से बार-बार हल किया जाता था. यह उपयोगकर्ता को ध्यान में रखकर बनाई गई टेक्नोलॉजी की मदद से हल की गई इंजीनियरिंग की समस्या थी. इसकी मदद से टीम को टेक्स्ट रेंडर करने के लिए, कोड के किसी हिस्से को फिर से लिखना होता था, ताकि दूसरी रिलीज़ में टेक्स्ट में बदलाव करने की सुविधा चालू की जा सके.

बार-बार की जाने वाली रिलीज़

पिछले दो सालों में इस प्रोजेक्ट को बेहतर बनाया गया है. टीम ने प्रोजेक्ट के रीड-ओनली वर्शन पर काम करना शुरू किया और कुछ महीनों बाद उन्होंने एक बिलकुल नया वर्शन भेजा, जिसमें बदलाव करने की कई सुविधाएं थीं. प्रोडक्शन के लिए कोड में बार-बार बदलाव करने के लिए, टीम ने फ़ीचर फ़्लैग का बड़े पैमाने पर इस्तेमाल करने का फ़ैसला किया. हर रिलीज़ के लिए, टीम नई सुविधाएं चालू कर सकती है और कोड में किए गए बदलावों को भी लागू कर सकती है. ये ऐसी नई सुविधाएं होती हैं जो उपयोगकर्ता को कई हफ़्तों बाद दिखती हैं. हालांकि, टीम को लगता है कि वे कुछ बेहतर कर सकते थे! उन्हें लगता है कि डाइनैमिक फ़ीचर फ़्लैग सिस्टम शुरू करने से काम तेज़ी से होगा. इससे फ़्लैग की वैल्यू को बदलने के लिए, फिर से डिप्लॉय करने की ज़रूरत नहीं पड़ेगी. इससे Goodnotes को ज़्यादा सुविधा मिलेगी और नई सुविधा के डिप्लॉयमेंट की रफ़्तार भी बढ़ेगी. क्योंकि Goodnotes को प्रोजेक्ट डिप्लॉयमेंट को प्रॉडक्ट की रिलीज़ से लिंक करने की ज़रूरत नहीं होगी.

ऑफ़लाइन काम

टीम ने जिन मुख्य सुविधाओं पर काम किया उनमें से एक है ऑफ़लाइन सहायता. अपने दस्तावेज़ों में बदलाव करने और उनमें बदलाव करने की सुविधा ऐसी एक सुविधा है जिसकी उम्मीद आपको इस तरह के किसी भी ऐप्लिकेशन से होगी. हालांकि, यह आसान सुविधा नहीं है, क्योंकि Goodnotes पर साथ मिलकर काम करने की सुविधा उपलब्ध है. इसका मतलब है कि अलग-अलग डिवाइस पर अलग-अलग उपयोगकर्ताओं की ओर से किए गए सभी बदलाव, हर डिवाइस पर ऐक्सेस होने चाहिए. साथ ही, इन बदलावों को उपयोगकर्ताओं से किसी भी विवाद को हल करने के लिए नहीं कहा जाना चाहिए. Goodnotes ने बहुत पहले ही इस समस्या को हल करने के लिए, CRDT टूल का इस्तेमाल किया था. बिना किसी टकराव वाले इन रिस्पॉन्स वाले डेटा टाइप की वजह से, Goodnotes किसी भी उपयोगकर्ता के किसी भी दस्तावेज़ में किए गए सभी बदलावों को जोड़ सकता है. साथ ही, मर्ज करने की प्रोसेस से जुड़े बिना किसी समस्या के बदलावों को मर्ज कर सकता है. IndexedDB और वेब ब्राउज़र के लिए उपलब्ध स्टोरेज, दोनों के इस्तेमाल से वेब पर साथ मिलकर काम करने में बहुत मदद मिली.

सबसे अहम बात यह है कि Goodnotes वेब ऐप्लिकेशन खोलने पर, आपको Wasm बाइनरी के साइज़ की वजह से, शुरुआती डाउनलोड की कीमत करीब 40 एमबी मिलेगी. शुरुआत में, Goodnotes की टीम पूरी तरह से ऐप्लिकेशन बंडल के लिए सामान्य ब्राउज़र कैश मेमोरी पर और इस्तेमाल किए जाने वाले ज़्यादातर एपीआई एंडपॉइंट पर निर्भर करती थी. हालांकि, अब उसे पहले ज़्यादा भरोसेमंद कैश एपीआई और सर्विस वर्कर से फ़ायदा मिल सकता था. शुरुआत में टीम अपनी मुश्किल लगने की वजह से इस काम से दूर रही थी, लेकिन आखिर में, टीम को एहसास हुआ कि वर्कबॉक्स ने इसे बहुत कम डरावना बनाया.

वेब पर Swift का इस्तेमाल करते समय सुझाव

अगर आपके पास कोई iOS ऐप्लिकेशन है, जिसमें बहुत से कोड हैं जिनका आप फिर से इस्तेमाल करना चाहते हैं, तो तैयार हो जाएं क्योंकि आप एक शानदार यात्रा शुरू करने वाले हैं. शुरू करने से पहले, आपको कुछ सलाह दिलचस्प लग सकती है.

• देखें कि आपको किस कोड का फिर से इस्तेमाल करना है. अगर आपके ऐप्लिकेशन का बिज़नेस लॉजिक, सर्वर साइड पर लागू किया गया है, तो हो सकता है कि आप अपने यूज़र इंटरफ़ेस (यूआई) कोड का फिर से इस्तेमाल करना पसंद करें. इसमें, Wasm से जुड़ी कोई मदद नहीं मिलेगी. टीम ने कुछ समय के लिए Tokamak के बारे में देखा, जो एक SwiftUI के साथ काम करने वाला फ़्रेमवर्क है. इसे WebAssembly की मदद से ब्राउज़र ऐप्लिकेशन बनाने के लिए इस्तेमाल किया जाता है. हालांकि, यह ऐप्लिकेशन की ज़रूरतों के हिसाब से पूरा नहीं था. हालांकि, अगर आपके ऐप्लिकेशन में क्लाइंट कोड के तौर पर, कारोबार के हिसाब से मज़बूत नियम या एल्गोरिदम लागू किए गए हैं, तो Wasm आपका सबसे अच्छा दोस्त होगा.
• पक्का करें कि आपका Swift कोड बेस तैयार है. यूज़र इंटरफ़ेस (यूआई) लेयर या खास आर्किटेक्चर के लिए सॉफ़्टवेयर डिज़ाइन पैटर्न, आपके यूज़र इंटरफ़ेस (यूआई) लॉजिक और आपके कारोबार के लॉजिक के बीच एक मज़बूत फ़र्क़ बनाते हैं. ये पैटर्न बहुत काम के होंगे, क्योंकि यूज़र इंटरफ़ेस लेयर को लागू करने की प्रोसेस को फिर से इस्तेमाल नहीं किया जा सकेगा. साफ़ आर्किटेक्चर या हेक्सागोनल आर्किटेक्चर से जुड़े सिद्धांत भी बुनियादी होंगे. इसकी वजह यह है कि आपको सभी IO से जुड़े कोड को इंजेक्ट करना होगा और इन पर डिपेंडेंसी देनी होंगी. साथ ही, इन आर्किटेक्चर को फ़ॉलो करना तब आसान होगा, जब लागू करने की जानकारी को 'कोई असर नहीं' के तौर पर बताया जाता है और डिपेंडेंसी से बदलने के सिद्धांत का बहुत ज़्यादा इस्तेमाल किया जाता है.
• Wasm के लिए यूज़र इंटरफ़ेस (यूआई) कोड उपलब्ध नहीं है. इसलिए, तय करें कि आपको वेब के लिए कौनसा यूआई फ़्रेमवर्क इस्तेमाल करना है.
• JSKit आपके Swift कोड को JavaScript के साथ इंटिग्रेट करने में आपकी मदद करेगा, लेकिन ध्यान रखें कि अगर आपके पास कोई हॉटपाथ है, तो JS–Swift ब्रिज को पार करना महंगा हो सकता है और आपको इसे एक्सपोर्ट किए गए फ़ंक्शन से बदलना होगा. आधिकारिक दस्तावेज़ में जाकर, JSKit कैसे काम करता है, इसके बारे में ज़्यादा जानने के लिए Swift में एक छिपा हुआ जेम! पोस्ट देखें.
• आप अपने आर्किटेक्चर का फिर से इस्तेमाल कर सकते हैं या नहीं, यह आपके ऐप्लिकेशन के फ़ॉलो किए जाने वाले आर्किटेक्चर और इस्तेमाल की जाने वाली एक सिंक कोड एक्ज़ीक्यूशन मैकेनिज़्म लाइब्रेरी पर निर्भर करता है. एमवीवीपी या कंपोज़ेबल आर्किटेक्चर जैसे पैटर्न की मदद से, अपने व्यू मॉडल और यूज़र इंटरफ़ेस (यूआई) लॉजिक के हिस्से को फिर से इस्तेमाल किया जा सकता है. ऐसा उन UIKit डिपेंडेंसी के साथ जोड़े बिना किया जा सकता है जिनका इस्तेमाल Wasm के साथ नहीं किया जा सकता. ऐसा हो सकता है कि RXSwift और दूसरी लाइब्रेरी, Wasm के साथ काम न करें. इसलिए, इसे ध्यान में रखें, आपको Goodnotes के Swift कोड में OpenCombine, async/await, और स्ट्रीम का इस्तेमाल करना होगा.
• gzip या ब्रोटली का इस्तेमाल करके Wasm बाइनरी को कंप्रेस करें. ध्यान रखें कि क्लासिक वेब ऐप्लिकेशन के लिए बाइनरी का साइज़ काफ़ी बड़ा होगा.
• भले ही, PWA के बिना Wasm का इस्तेमाल किया जा सकता हो, लेकिन आपको कम से कम एक सर्विस वर्कर को शामिल करना होगा. भले ही, आपके वेब ऐप्लिकेशन में कोई मेनिफ़ेस्ट न हो या उपयोगकर्ता इसे इंस्टॉल न करे. सर्विस वर्कर, Wasm बाइनरी को मुफ़्त में और ऐप्लिकेशन के सभी संसाधनों को सेव करके उपलब्ध कराएगा, ताकि उपयोगकर्ता को हर बार आपका प्रोजेक्ट खोलने पर उन्हें डाउनलोड करने की ज़रूरत न पड़े.
• ध्यान रखें कि नौकरी पर रखने में उम्मीद से ज़्यादा मुश्किल आ सकती है. हो सकता है कि आपको ऐसे मज़बूत वेब डेवलपर को काम पर रखना पड़े जिनके पास Swift का कुछ अनुभव हो या जिनके पास वेब का कुछ अनुभव हो. अगर आपको दोनों प्लैटफ़ॉर्म पर कुछ जानकारी रखने वाले सामान्य इंजीनियर मिल जाएं, तो यह बहुत अच्छी बात होगी.

मीटिंग में सामने आए नतीजे

चुनौतियों से भरे प्रॉडक्ट पर काम करते हुए मुश्किल टेक्नोलॉजी स्टैक का इस्तेमाल करके वेब प्रोजेक्ट बनाना, एक बेहतरीन अनुभव है. यह कठिन होगा, लेकिन यह सही है. Goodnotes ने iOS ऐप्लिकेशन के लिए नई सुविधाओं पर काम करते समय इस तरीके का इस्तेमाल किए बिना, Windows, Android, ChromeOS, और वेब के लिए कभी कोई वर्शन रिलीज़ नहीं किया हो सकता. इस टेक्नोलॉजी स्टैक और Goodnotes की इंजीनियरिंग टीम को धन्यवाद. Goodnotes अब हर जगह उपलब्ध है और टीम अगली चुनौतियों पर काम करने के लिए तैयार है! अगर आपको इस प्रोजेक्ट के बारे में ज़्यादा जानना है, तो NSस्पेन 2023 में Goodnotes की टीम के दिए गए टॉक शो को देखें. वेब के लिए Goodnotes को आज़माना न भूलें!