LLM-सहायित प्रोग्रामिंग के दौर में, फिलहाल Swift की प्रोडक्टिविटी कम है

• Swift 6 और नवीनतम iOS ऐप डेवलपमेंट में LLM-आधारित टूल्स का उपयोग काफी कम प्रभावी है, जिससे Android (Kotlin, Compose, Cursor के उपयोग) की तुलना में प्रोडक्टिविटी गैप काफी बढ़ गया है
• Android टीम नवीनतम फीचर्स को पुराने OS तक सपोर्ट करते हुए तेज़ डेवलपमेंट कर सकती है, लेकिन iOS टीम नवीनतम Swift 6 सिंटैक्स, फीचर सीमाओं और फ्रेमवर्क सपोर्ट की कमी के कारण प्रोडक्टिविटी में गिरावट और कोडबेस ट्रांज़िशन का बोझ झेल रही है
• LLM, Swift 6 के नए concurrency मॉडल और जटिल पैटर्न को समझ नहीं पा रहा, इसलिए LLM की कोड ऑटोमेशन/एक्सेलेरेशन क्षमता सीमित हो जाती है
• Swift 6 का अपनाया जाना स्वयं कुछ डेवलपर्स के लिए सकारात्मक माना जाता है, लेकिन LLM टूल्स के साथ कम्पैटिबिलिटी की कमी को समस्या के रूप में देखा जा रहा है
• Android, Compose, Cursor आदि Google ecosystem की backward compatibility और developer-friendly approach उभरकर सामने आ रही है, जबकि Swift/Apple पक्ष में फ्रेमवर्क और API अपडेट की गति को लेकर असंतोष जारी है

---

Swift 6 और LLM युग में डेवलपमेंट प्रोडक्टिविटी

iOS vs Android डेवलपमेंट प्रोडक्टिविटी का अनुभव

• लेखक एक छोटी iOS टीम में Swift 6 के साथ नया ऐप डेवलप कर रहे हैं, और साथ ही एक छोटी Android टीम के साथ समानांतर डेवलपमेंट भी चल रहा है
• Android टीम Kotlin, Compose, Cursor के उपयोग से तेज़ गति और नवीनतम फीचर सपोर्ट हासिल कर रही है, और 2019 में जारी Android 10 तक व्यापक सपोर्ट दे पा रही है
• iOS टीम केवल iOS 16 (2022) और उससे ऊपर को सपोर्ट कर सकती है, और नवीनतम Swift 6 अपनाने के कारण Observable, generic parameter packs जैसे कई फीचर प्रतिबंधों का सामना कर रही है

Swift 6 और LLM के बीच असंगति

• Swift 6 में बड़े पैमाने पर सिंटैक्स और फ्रेमवर्क बदलाव का समय LLM (बड़े भाषा मॉडल) सपोर्ट के दौर से टकराया, और LLM Swift 6 के नए concurrency सिस्टम को ठीक से संभाल नहीं पा रहा
• कोड को अपने-आप जनरेट या रिकमेंड करने वाले LLM टूल्स (जैसे ChatGPT, Claude, Cursor आदि) ने Swift 6 से जुड़े डेटा और पैटर्न को पर्याप्त रूप से नहीं सीखा है, इसलिए सटीक कोड जनरेशन में सीमाएँ हैं
• डेवलपर्स को उन हिस्सों में, जिन्हें LLM ठीक से नहीं समझता, मैन्युअली context समझाकर और नियम जोड़कर पूरक करना पड़ता है → इससे प्रोडक्टिविटी घटती है और दोहराव वाला काम बढ़ता है

कम्युनिटी की राय और अनुभव

• कुछ iOS डेवलपर्स ने Android की API backward compatibility, Compose UI की परिपक्वता, और Cursor टूल को लेकर ईर्ष्या जताई
• कुछ का मानना है कि Swift 6 अपनाना गलत फैसला था, लेकिन वास्तव में नए पैटर्न और सीखने की ज़रूरत को स्वीकार करते हुए कोड की अभिव्यक्ति और गुणवत्ता बढ़ने की सकारात्मक राय भी मौजूद है
• Apple के प्रमुख फ्रेमवर्क अभी तक Swift 6 concurrency सिस्टम के अनुरूप ठीक से अपडेट नहीं हुए हैं, जिससे GCD के साथ मिश्रित उपयोग जैसी स्थितियों में कोड की जटिलता और प्रोडक्टिविटी में गिरावट का अनुभव साझा किया गया
• कुछ टीमें Swift 6 को अपनाने में देरी कर रही हैं और पहले मौजूदा कोडबेस के साथ कम्पैटिबिलिटी समस्याएँ सुलझा रही हैं

Android और Apple ecosystem का अंतर

• Android, नई API के backward compatibility (Backport) policy के जरिए डेवलपर प्रोडक्टिविटी को मजबूत कर रहा है, और लंबे समय से चली आ रही कमियों (fragmentation, device-specific bugs आदि) पर काबू पा रहा है
• इसके विपरीत Apple में private/सीमित API और धीमी अपडेट policy के कारण डेवलपर्स पर बार-बार समान फीचर्स खुद लागू करने का बोझ रहता है
• Compose, Cursor जैसे AI और automation टूल्स अपनाने से Android डेवलपमेंट प्रोडक्टिविटी और तेज़ी से बढ़ रही है
• iOS और Swift डेवलपर्स के बीच, LLM का प्रभावी उपयोग कठिन होने के इस दौर में डेवलपमेंट ट्रेंड में बदलाव और career position को लेकर असुरक्षा की भावना बढ़ने के उदाहरण सामने आ रहे हैं

निष्कर्ष और व्यावहारिक संकेत

• Swift 6 की नवाचार क्षमता और कोड अभिव्यक्ति को सराहा जाता है, लेकिन LLM और AI coding टूल्स की सीमाओं के कारण फिलहाल मैन्युअल काम और बार-बार समझाना अपरिहार्य है
• जिन प्रोजेक्ट्स में तेज़ डेवलपमेंट और नवीनतम फीचर्स का उपयोग ज़रूरी है, वहाँ Android + Compose + Cursor का संयोजन प्रोडक्टिविटी के मामले में बेहद प्रभावशाली है
• जब तक Apple फ्रेमवर्क और टूल ecosystem के अपडेट तेज़ नहीं करता, तब तक Swift 6 अपनाने वाले डेवलपमेंट वातावरण में प्रोडक्टिविटी में गिरावट और LLM उपयोग की सीमाएँ झेलनी पड़ेंगी

[undercat]

कुल मिलाकर बात सही है, लेकिन MLX के साथ Apple Silicon डिवाइसों पर लोकल मॉडल्स को थोड़ी देर चलाकर देखने के अपने अनुभव के हिसाब से इससे 100% सहमत होना मेरे लिए मुश्किल है।

[yangeok]

संदर्भ के लिए, मॉडल डेवलपमेंट करते समय इसे mlx में port करना पड़ने का बोझ भी है, और mps को activate करने पर भी अनुभव के हिसाब से computation बस CPU से थोड़ा ही तेज़ लगता है, इसलिए अभी भी यह असुविधाजनक है।

[elddytbt]

आह.. बहुत दर्द हुआ, सीधा दिल पर लगा...