LinkedIn ऐप लगभग आधा गिग क्यों है?
LinkedIn का iOS ऐप लगभग आधा गिगाबाइट तक बढ़ गया है, जिससे यह सवाल उठा है कि बड़े कॉर्पोरेट ऐप्स कैसे duplicated libraries, छोड़े गए features, और PM-चालित feature creep के कारण फुलाव जमा करते हैं, न कि जानबूझकर की गई engineering से। टिप्पणीकार Uber जैसे मामलों से इसकी तुलना करते हैं, जहाँ कुछ आकार जटिल localization और regional feature sets से उचित ठहराया जा सकता है, और तर्क देते हैं कि संगठनात्मक प्रोत्साहन, न कि टेक स्टैक, अक्षमता के मुख्य चालक हैं। कई लोग सीमित devices वाले users के लिए व्यावहारिक नुकसान की ओर इशारा करते हैं और इसे खराब रूप से optimized web और mobile software की व्यापक समस्या का हिस्सा मानते हैं, जहाँ size और performance शायद ही कभी product metrics में मायने रखते हैं।
ऐप का आकार और दिखाई देने वाली फुलावट
- LinkedIn का iOS ऐप लगभग ~500 MB तक पहुँचता है; थ्रेड में कुछ विश्लेषण बताते हैं कि सिर्फ़ dynamic frameworks/plugins ही 300 MB+ हैं, और एक Today Extension जो <1 MB से बढ़कर ~60 MB हो गई, जबकि Apple ने उसे deprecated कर दिया था।
- कई लोगों के अनुसार यह “death by a thousand cuts” जैसा है: समय के साथ frameworks, plugins, और duplicated assets बार-बार जुड़ते जाते हैं, न कि कोई एक बड़ा फ़ीचर।
- कई लोग इसकी तुलना दूसरी फूली हुई apps (banks, email, chat widgets, login SDKs) से करते हैं, और LinkedIn के web client से भी, जो >1 GB RAM और भारी CPU तक पहुँच सकता है।
Localization और फ़ीचर की व्यापकता
- Uber को एक उदाहरण के रूप में लिया गया है जहाँ ऐप का आकार आंशिक रूप से localization और region-specific logic से आता है: translations, currencies, payment SDKs, और हर देश या शहर के लिए अलग-अलग ride types और flows।
- कुछ लोग सवाल उठाते हैं कि सिर्फ़ strings इतनी बड़ी कैसे हो सकती हैं; दूसरे बताते हैं कि यहाँ “localization” में feature sets, flows, guides, tax/regulation screens, और region-specific services भी शामिल हैं।
- LinkedIn के लिए लोग travel-related locale जरूरतों से कम और bundled global functionality तथा frameworks से ज़्यादा संबंध मानते हैं।
संगठनात्मक और प्रोत्साहन संबंधी समस्याएँ
- कई टिप्पणियाँ तर्क देती हैं कि मूल कारण टेक स्टैक नहीं, संगठन है:
- बड़े teams, PM-चालित “feature frenzy,” resume-driven development, और ऐसे OKR systems जो दिखने वाले features ship करने को reward करते हैं, performance या size को नहीं।
- Architects और code reviews को deadline pressure और politics के सामने काफी हद तक असहाय बताया गया है।
- Perf और size regressions नया baseline बन जाते हैं; refactors को “fix later” tickets में टाल दिया जाता है जो कभी पूरे नहीं होते।
User experience, dark patterns, और mobile web
- कई लोग शिकायत करते हैं कि LinkedIn का mobile web experience जानबूझकर खराब किया जाता है, ताकि app install करने के लिए nags मिलें; इससे भारी होने के बावजूद ऐप और केंद्रीय बन जाता है।
- ऐसे ही व्यवहार अन्य services में भी नोट किए जाते हैं (जैसे forced locale changes, tracking consent से जुड़ी cookie-based “personalization”)।
- कुछ इसे user-hostile और trust-reducing मानते हैं, और ऐसे apps install ही नहीं करते।
Users और installs पर प्रभाव
- कई लोगों का तर्क है कि ऐप का आकार installations को प्रभावित करता है, खासकर सीमित storage या data वाले users के लिए; दूसरे कहते हैं कि stores के पास ऐसे analytics होते हैं जो इसे उजागर कर सकते हैं।
- Counterpoint: एक मत यह भी है कि LinkedIn के target users के लिए storage और bandwidth काफ़ी सस्ते हैं, इसलिए 500 MB का app स्वीकार्य है।
“Size core problem नहीं है” वाला दृष्टिकोण
- एक छोटा समूह बड़े apps का बचाव करता है: LinkedIn एक जटिल “super-app” है, और tight optimization की बजाय developer velocity को प्राथमिकता देना तर्कसंगत है।
- उनका कहना है कि install size अपने-आप खराब runtime performance का मतलब नहीं है, हालांकि दूसरे लोग ऐसे उदाहरण देते हैं जहाँ bloat और slowness साफ़ तौर पर साथ-साथ चलते हैं।