वेब के लिए कोड लिखना

 (mrmr.io)
1 पॉइंट द्वारा GN⁺ 2024-02-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Apple ग्राहकों को सुरक्षित और कम प्रबंधन-झंझट वाले डिवाइस देता है, लेकिन व्यक्तिगत डेवलपर्स के लिए उसी स्तर की परस्पर निर्भरता नहीं बनाता — ऐसा एक अनुभवजन्य निष्कर्ष निकाला गया है
  • Google Search का dark/light mode bug इस बात के उदाहरण के रूप में लिया गया है कि ऐसी असुविधाएँ जिनका revenue पर असर नहीं पड़ता, लंबे समय तक अनदेखी रह सकती हैं
  • Apple का मुख्य मूल्य app ecosystem से ज़्यादा ऐसे कंप्यूटर और डिवाइस में है जिन्हें उपयोगकर्ता बिना अलग प्रबंधन के इस्तेमाल कर सकें; iPhone या iPad को app के बिना भी खरीदने की वजह मौजूद है
  • 2016 में जिस Apple Music API से बड़ी उम्मीदें थीं, उसमें 8 साल बाद भी bugs और access restrictions बने हुए हैं, और सिर्फ़ साधारण परीक्षण के लिए भी $100 प्रति वर्ष का developer account चाहिए
  • किसी एक कंपनी की मालिकाना हक़ वाली नहीं होने वाली web platform अपूर्ण और नाज़ुक है, लेकिन किसी खास कंपनी की zero-sum संरचना से कम बँधना चाहने वाले डेवलपर्स के लिए यह अब भी एक व्यावहारिक विकल्प है

Apple ग्राहकों के लिए मज़बूत है, लेकिन डेवलपर्स पर निर्भर नहीं

  • Apple अपने ग्राहक यानी व्यक्तियों को स्पष्ट मूल्य देता है, लेकिन individual developers के लिए उसी तरह ध्यान देने की संरचनात्मक वजह कमज़ोर है — यह इस लेख का केंद्रीय विचार है
  • निर्भरता का संबंध Developer -> Apple, Apple -> Consumer की दिशा में बहता है, और Apple से individual developer की ओर जाने वाली उलटी निर्भरता लगभग नहीं के बराबर मानी गई है
  • अगर सभी डेवलपर्स Apple platform के लिए development बंद भी कर दें, तो भी Apple बड़े पैमाने पर जीवित रह सकता है, क्योंकि उसका मुख्य value proposition व्यक्तिगत डेवलपर्स पर टिका नहीं है
  • enterprise developers “partners” के साथ सहयोग ज़रूरी हो सकता है, लेकिन वह individual developers पर निर्भरता से अलग बात है
  • कुछ बहुराष्ट्रीय कंपनियाँ developers को अपनी strategy का केंद्र बनाती हैं, लेकिन Apple को उस तरह की कंपनी नहीं माना गया है
  • इस भेद को स्वीकार करने के बाद Apple products को पसंद करने और Apple के लिए development करना चाहने की भावनाओं को अलग-अलग देख पाना संभव हुआ

Google का उदाहरण: revenue पर असर न डालने वाले bugs लंबे समय तक रह सकते हैं

  • Google Search में यह समस्या है कि dynamic light/dark mode में system बदलने पर पहला search results page उलटे theme में दिखता है
    • रात में पूरा system dark होने पर भी पहला results page चमकदार light theme में खुलता है, जिससे आँखों में तकलीफ़ होती है
    • सुबह laptop के light mode में लौटने के बाद search results पढ़ने में मुश्किल काले background पर दिखाई देते हैं
  • यह bug कई सालों से बना हुआ है, और माना गया है कि बड़े redesign के दौरान संयोग से ठीक न हो जाए तो इसके सुधरने की संभावना कम है
  • इसकी वजह Google में इसे ठीक करने की क्षमता की कमी नहीं, बल्कि revenue पर असर न होना मानी गई है
  • DDG जैसे alternative search engine इस्तेमाल करने वाले लोग पहले ही जा चुके हैं, और भारी बहुमत अब भी Google से बँधा हुआ है
  • DDG privacy-friendly होने की बात करता है, लेकिन उसे इस्तेमाल करने की असली वजह शुरुआती Google की याद दिलाने वाला simple UX, अच्छी quality के exact search results, और non-intrusive ads हैं
  • Google उपयोगकर्ताओं को game-theoretic लक्ष्य की तरह नहीं देखता, और Google products इस्तेमाल करते समय होने वाली user-hostile interactions भी उसी संरचना का परिणाम मानी जाती हैं

Apple का मुख्य मूल्य: सुरक्षित कंप्यूटर जिनकी देखभाल का बोझ कम हो

  • लगभग 2009 के आसपास परिवार के लिए कंप्यूटर चुनते समय यह आकलन किया गया कि उस समय Windows सुरक्षा के लिहाज़ से बहुत कमज़ोर था, और Linux को लगातार technical support की ज़रूरत पड़ती थी
  • अंततः OpenBSD, Firefox, और basic games के साथ एक कंप्यूटर तैयार किया गया, लेकिन सुरक्षा, privacy, और कम support burden पाने की कीमत पर usability बहुत सीमित हो गई
  • iOS app कंपनी में काम के लिए Mac इस्तेमाल करने के बाद यह निष्कर्ष निकला कि “यही वह कंप्यूटर है जो मैं अपनी माँ के लिए चाहता था”
  • पैसे बचाकर MacBook खरीदा गया, और समय के साथ परिवार का form factor laptop से iPad में बदल गया, लेकिन वही मुख्य मूल्य लगातार पूरा होता रहा
  • app के बिना भी iPhone को अपने लिए खरीदा जा सकता है, और परिवार के लिए तो लगभग निश्चित रूप से खरीदा जाएगा — ऐसा माना गया है
  • Apple के business model में developers अनिवार्य तत्व नहीं हैं; developers खुश रहें तो अच्छा है, लेकिन पूरी संरचना इस पर निर्भर नहीं करती कि वे खुश हों ही
  • Apple के भीतर ऐसे लोग हैं जो developers की परवाह करते हैं और सुधार लाना चाहते हैं, लेकिन कंपनी-स्तर का व्यवहार हमेशा एकसमान नहीं हो सकता

Apple Music API को लेकर उम्मीद और निराशा

  • लगभग 2016 में WWDC में Apple Music API की घोषणा होने पर बड़ी उम्मीदें थीं, लेकिन वास्तव में “सब कुछ बदल जाएगा” जैसी कोई बात नहीं हुई
  • Apple का अपना music player अब भी इस्तेमाल में कठिन महसूस होता है, और जिन alternative players को आज़माया गया वे भी ज़्यादातर Spotify-शैली के approach का पालन करते हैं
  • Winamp के Justin Frankel वाले दौर की तरह तेज़, smooth, अंतहीन रूप से चलने वाला और निजी एहसास देने वाला music player experience फिर से बनाया जा सकता है — ऐसी उम्मीद थी
  • यह भी माना गया कि अगर Apple का music catalog मिल जाए, तो पहले की तरह piracy पर निर्भर हुए बिना उस अनुभव को फिर बनाया जा सकता है
  • खाली समय मिलने पर Flowers नाम का music player बनाया गया, और यह इरादा भी था कि दूसरे लोग अपने-अपने music players बना सकें, इसलिए tutorial भी लिखा जाए
  • implementation के दौरान यह निष्कर्ष निकला कि 8 साल बाद भी API buggy है और खुली नहीं है
    • API को सिर्फ़ test करने के लिए भी Apple को $100 प्रति वर्ष देने पड़ते हैं
    • यह शुल्क बड़े पैमाने के usage के लिए नहीं, बल्कि सिर्फ़ साधारण परीक्षण access के लिए भी है
    • paid developer account होने पर भी केवल सीमित API ही मिलती है
  • Apple के web music player के browser console में MusicKit.getInstance().developerToken डालने पर बिना restriction वाला root token मुफ़्त में मिल जाता है, इसलिए developer प्रक्रिया को अव्यवहारिक माना गया है

वेब एक साझा platform है जिसका कोई एक मालिक नहीं

  • निष्कर्ष अंततः web पर चलने वाला code लिखने की दिशा में जाता है
  • web एक shared platform है जिसका मालिक कोई एक entity नहीं है, और इस अर्थ में यह किसी कंपनी-नियंत्रित platform से अलग है कि सद्भावना भी अयोग्यता के कारण इसे नुकसान पहुँचा सकती है
  • web platform निम्न कारणों से नाज़ुक स्थिति में है
    • अत्यधिक हस्तक्षेप करने वाली सरकारें
    • browser duopoly
    • जटिल developer ecosystem
  • इस बात की कोई गारंटी नहीं कि web हमेशा फलता-फूलता रहेगा, लेकिन यह अब तक बचा रहा है, और जितना अधिक समय तक यह टिकेगा, आगे भी इसके फलने-फूलने की संभावना उतनी बढ़ेगी
  • web से जुड़ा हाल का workaround Safari के अजीब व्यवहार की वजह से लिखना पड़ा था
  • साथ ही, Google web के लिए शानदार काम भी कर रहा है, इसलिए इस संदर्भ में उसकी भूमिका अच्छी मानी गई है

कंपनियों के साथ संबंध को स्थायी अच्छाई-बुराई में बाँटना मुश्किल है

  • जैसे लोगों को स्थायी रूप से अच्छे और बुरे लोगों में बाँटना उपयोगी नहीं, वैसे ही कंपनियों को भी हमेशा के लिए अच्छी या बुरी कंपनी कहना कठिन है
  • कंपनियाँ बुद्धि, स्वभाव, जन्म, विकास, अंत, और कानूनी व्यक्तित्व जैसी विशेषताओं में लोगों से मिलती-जुलती मानी गई हैं
  • जैसे हम लोगों के बिना नहीं जी सकते, वैसे ही कंपनियों के बिना भी नहीं; और भले उनमें अमानवीय गुण हों, मानव संगठनों के fractal रूप बने रहते हैं
  • अगर कंपनियों को अच्छाई-बुराई की स्थायी श्रेणियों में न रखा जाए, तो उनसे अधिक लचीले ढंग से संबंध बनाए जा सकते हैं
    • जब कोई कंपनी आपको zero-sum game में धकेले, तो उस पर निर्भरता घटाई जा सकती है
    • और जब वह अधिक symbiotic संबंध की अनुमति दे, तो फिर से उसमें शामिल हुआ जा सकता है
  • Steve Jobs ने 1996 में कहा था कि बड़ी, मध्यम और छोटी सभी कंपनियाँ web को अंततः सीधे ग्राहक तक पहुँचने वाले distribution channel के रूप में देखने लगी थीं — एक ऐसा रास्ता जो बिचौलियों को दरकिनार कर supplier से consumer तक सीधे जाता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-02-05
Hacker News की राय

  • शुरुआत में मैंने native mobile development न सीखने का फैसला किया और अपना सीमित समय पूरी तरह web पर लगाया; इस बार मुझे लगता है कि यह सही चुनाव था
    आज browser में कमाल की चीज़ें बनाई जा सकती हैं, और मेरी बेहद निजी राय में Uber, Google Drive और games जैसी कुछ चीज़ों को छोड़कर ज़्यादातर apps web apps ही होने चाहिए थे
    मैं media industry में काम करता था, और हमारे देश में 2010 के शुरुआती साल ऐसे थे जब बहुत कम पैसे वाले media outlets भी mobile apps बनाने में budget झोंक रहे थे; मैं उस trend का विरोध करने वाला अलग-थलग व्यक्ति था
    मुझे पता था कि ज़्यादातर apps की quality अच्छी नहीं होगी, और कंपनियां अपने mobile front को लगातार update भी नहीं करेंगी; आखिर में ठीक वैसा ही हुआ
    अब हम उन apps में फंसे हैं जिनकी लगभग maintenance भी नहीं होती, और उनमें से ज़्यादातर बीते दौर के अवशेष जैसे दिखते हैं—असल में वे हैं भी वही

    • मैं समझता हूं कि Google Drive native app में बेहतर चलता है। आखिर उसे operating system को virtual filesystem देना होता है और background sync जैसी चीज़ें करनी होती हैं
      लेकिन Uber क्यों, यह समझ नहीं आता। Uber के पास ride request और app के लगभग सारे काम अच्छी तरह संभालने वाली mobile site है या थी, और यह साफ नहीं दिखता कि native app user को क्या अतिरिक्त value देता है
      ज़्यादातर mobile games के साथ भी यही है। आम तौर पर graphics सरल होते हैं जिन्हें browser पर्याप्त performance के साथ render कर सकता है, और common UI components अक्सर खुद से दोबारा बनाए जाते हैं, इसलिए native system buttons न इस्तेमाल कर पाना बड़ा फर्क नहीं डालता
      PWA भी local saved files और game data के लिए ज़रूरी storage पर्याप्त दे सकता है। हां, system limits तक धकेलने वाले games अपवाद हैं
      मैं उम्मीद नहीं करता कि Death Stranding या RE4 remake जैसे games native graphics acceleration तक direct access के बिना अच्छी तरह चलेंगे, और वे एक single webpage के रूप में load करने के लिए बहुत बड़े हैं
      लेकिन ज़्यादातर mobile apps, यहां तक कि web पर जाने से 30% ज्यादा revenue अपने पास रख सकने वाले high-revenue free-to-play games भी, इस श्रेणी में नहीं आते
      फिर वे web को target क्यों नहीं करते? मेरा intuition है कि mobile users को apps और games App Store में ढूंढने की आदत डाल दी गई है, जबकि desktop users—कुछ specialized tools और high-end games को छोड़कर—उम्मीद करते हैं कि apps browser में मिलेंगे
      आखिरकार इसका बड़ा हिस्सा cultural issue है, और Apple का कमजोर PWA support भी मदद नहीं करता
    • काश web development experience इतना frustrating न होता। पिछले 10 साल में इसमें काफी सुधार हुआ है, लेकिन native development environment की तुलना में यह अभी भी optimal नहीं लगता
      इस frustration का बड़ा हिस्सा tooling, खासकर TypeScript, से आता है; इसे संक्षेप में समझाना मुश्किल है, लेकिन native side की तुलना में TypeScript type system से जूझना मुझे कहीं ज्यादा पड़ा
    • खास तौर पर offline-first तरीके से बनाए गए PWA पांच साल पहले की तुलना में native experience के कहीं ज्यादा करीब आ गए हैं
      हालांकि चिंता यह है कि क्या Google और Apple के पास PWA को native apps से प्रतिस्पर्धा करने लायक बेहतर बनाने में मदद करने की कोई incentive है। उस स्तर पर पहुंचने पर उनकी revenue पर असर पड़ सकता है
    • हर महीने बदलने वाली fashionable technologies में समय क्यों लगाना?
      technology stack के fundamental building blocks में समय लगाना बेहतर है
    • phones और tablets को तरह-तरह के बेकार apps से भरा देखना बहुत थका देता है। पास के parking lot का भी app है, library copier का भी app है
      ये सब web से किया जा सकता है

  • Apple developers की परवाह क्यों नहीं करता, इसका कारण वही है जो उसने खुद समझाया है: users की तरफ उसने walled garden जैसा cult बना रखा है
    developers अगर उस platform के लिए product नहीं बनाते, तो market का आधा या उससे भी ज्यादा हिस्सा खो देते हैं
    एक बड़ी कंपनी के भीतर छोटे studio में mobile games बनाना मेरा day job है, और वहां हमें Apple से सिर्फ technical issues पर ही नहीं, policy और approval issues पर भी लगातार लड़ना पड़ता है
    लेकिन ऐसा mobile game release करना जिसकी iOS पर चलने की कोई राह न हो, सोचना मुश्किल है, इसलिए मानना ही पड़ता है
    कई मायनों में Microsoft की मूल PC strategy ठीक उलटी थी। उसने developers का ख्याल रखा और विशाल documentation, examples और tools दिए
    उन developers की कंपनियों के पास Microsoft के लिए software बनाने, promote करने और बेचने की motivation थी, और individual developers द्वारा Windows software की बाढ़ ने वही desktop operating system बनाया जो आज भी dominant है

    • 15 साल से professional तौर पर software लिख रहा हूं, लेकिन Apple devices के लिए code की एक भी line नहीं लिखी, और आगे भी नहीं लिखूंगा
      Apple ecosystem में योगदान देना choice है, compulsion नहीं। जो developers Apple ecosystem में योगदान देते हैं, वे मौजूदा स्थिति में सक्रिय रूप से भाग ले रहे हैं
    • मुझे लगता है वजह यह है कि Apple एक hardware company है और consumers को आकर्षित करने के लिए software का इस्तेमाल करती है, जबकि Microsoft एक software company है और consumers को आकर्षित करने के लिए hardware का इस्तेमाल करती है
    • Apple developers को कुछ करने के लिए force नहीं करता। developers उस platform के लिए apps इसलिए बनाते हैं क्योंकि consumers वहां पैसे खर्च करना चाहते हैं
      Apple developers के साथ सख्ती करके—या ज्यादा सटीक कहें तो developers को customers के साथ बदसलूकी न करने देकर—यह हासिल करता है
      यह suppliers पर कड़ा दबाव डालने वाली approach जैसी भी है, लेकिन आखिर में एक healthy और wealthy ecosystem बना है, और developers व suppliers अब भी वहां apps दे रहे हैं
    • यह बात लेखक द्वारा बताई गई स्थिति से थोड़ी अलग लगती है। लगता है लेखक उन services पर focus कर रहा था जो किसी भी situation में meaningful हैं, और mobile सिर्फ कई access points में से एक है
      जैसे social networks, dating apps, Reddit, Stack Overflow। ये Uber जैसी location tracking मांगने वाली services या mobile games जैसी services नहीं हैं जो चलते-फिरते खेलने के लिए design होती हैं और mobile experience पर निर्भर करती हैं
      अगर business mobile experience पर निर्भर नहीं है, तो native app के बिना भी service दी जा सकती है
      mobile users भी mobile browser से access कर सकते हैं, और भले ideal experience न हो, यह एक option तो है
      मुझे लगता है core बात यह है कि अगर mobile platform अनिवार्य नहीं है या उस पर dependency नहीं है, तो उसके लिए मत बनाइए
    • mobile games के मामले में Apple ने किन चीज़ों पर रोक लगाई, यह जानने की उत्सुकता है

  • कुछ साल पहले मैंने Swift और native iOS development सीखने के लिए गहराई से कोशिश की थी, लेकिन Xcode इस्तेमाल करने की आदत किसी तरह नहीं डाल पाया
    Xcode का UI/UX बयान करना मुश्किल है, इतना खराब था; ऐसे icons दबाने के लिए panels बार-बार खोलने-बंद करने पड़ते थे जो intuitively grouped भी नहीं थे
    एक panel खोलते ही दूसरा panel जबरन minimize हो जाता था, और ऐसा लगता था कि समय का लगभग दसवां हिस्सा असल में “panel driving” में जा रहा है
    लगता है Apple के designers developers के लिए कम friction वाला IDE नहीं, बल्कि visually सुंदर और minimal IDE बनाना चाहते थे
    लेकिन IDE को minimal होने की जरूरत नहीं है; हर developer जो बनाना चाहता है उसके हिसाब से उसे जितना चाहे customize और messy रखने की आज़ादी होनी चाहिए
    अगर किसी physical garage workbench की कल्पना करें, तो Visual Studio आपको workspace को मनचाहा messy और customized रखने देता है, लेकिन Apple जैसे हर अगला tool उठाने से पहले पिछला tool box में रखने को कहता हो
    मैं panel driving से यही मतलब ले रहा हूँ, और जानना चाहता हूँ कि क्या दूसरे developers भी ऐसा ही महसूस करते हैं

    • यह बात सच में बहुत resonate करती है, और native Mac/iOS development कई बार try करके छोड़ देने की मेरी वजह ठीक-ठीक IDE ही थी
      “function से पहले form” वाली बात ने मुझे शब्दों में समझा दिया कि Xcode में मुझे क्या नापसंद था
      मैं 10 साल से ज्यादा JetBrains ecosystem में रहा हूँ और उसकी कमियाँ भी हैं, लेकिन मुझे कभी ऐसा नहीं लगा कि JetBrains IDE को मेरी पसंद के तरीके से काम करने से रोक रहा है
    • मैं सहमत हूँ कि Xcode usability सचमुच भयानक है। यह अविश्वसनीय रूप से slow है और इतनी बार crash होता है कि App Store review में होता तो पास नहीं हो पाता
      लेकिन Apple platforms के लिए native apps बनाते समय मुझे सच में दूर करने वाली चीज़ bugs और documentation की कमी का combination था
      एक साल पहले जब आखिरी बार इस्तेमाल किया था, SwiftUI अपने उद्देश्य के लायक हालत में नहीं था, और ज्यादा mature libraries तक में अक्सर documentation लगभग नहीं होती थी
      यह जानना भी मुश्किल है कि क्या deprecated हो चुका है
      मेरे काम में native app के फायदे user के नजरिए से शुरू से ही छोटे हैं, मुख्यतः थोड़ा ज्यादा reliable local storage
      अगर productivity webapp बनाने से बहुत कम है, तो monopolistic राजा जैसी सत्ता की मेहरबानी पर निर्भर रहने की extra cost और risk को justify करना मुश्किल है
    • मुझे लगता है यह development style और familiar environment पर काफी निर्भर करता है
      Xcode मुझे बिल्कुल परेशान नहीं करता, लेकिन इतना सराहा जाने वाला IntelliJ-based Android Studio लगातार irritate करता है
      Visual Studio भी इसी तरह frustrating है और उसमें अजीब limits हैं। जैसे syntax highlighting में italic क्यों इस्तेमाल नहीं कर सकते, समझ नहीं आता
      editors के साथ भी यही है। VS Code में Sublime Text या TextMate के उलट छोटी-छोटी irritations हैं
    • सहमत हूँ। दूसरे IDEs में आसानी से मिलने वाली Build Output या Project Settings जैसी चीज़ें खोजने की कोशिश करते हुए मैं अक्सर भटक जाता हूँ, और वह panel कैसे खोलना है यह Google पर search करना पड़ता है
    • निजी तौर पर Xcode शानदार भी है और भयानक भी। VS Code में होता हूँ तो इसकी कमी महसूस होती है, लेकिन Xcode के अंदर होता हूँ तो इससे नफरत होने लगती है—पता नहीं यह बात समझ आती है या नहीं
      यह पुराने भारी-भरकम IDE जैसा लगता है; जितना आप उसके तरीके से चलते हैं उतना comfortable होता जाता है, लेकिन साथ ही यह एहसास रहता है कि control मेरे हाथ में नहीं है
      अगर Apple ने ध्यान दिया होता तो VS Code जितना नहीं तो कम से कम आधा ज्यादा responsive बना सकता था, और यह यकीनन अभी से बेहतर हो सकता था
      Vim key bindings का support खराब होना ही गुस्सा दिलाने के लिए काफी है। जैसे c या r जैसी ज्यादातर actions को repeat नहीं कर सकते
      उस समय आपने SwiftUI इस्तेमाल किया था या UIKit के storyboards से लड़ रहे थे, पता नहीं, लेकिन बाद वाला इतना खराब experience है कि दुश्मन को भी recommend नहीं करूँगा
      SwiftUI अभी शुरुआती stage में है इसलिए polish की जरूरत है, फिर भी उसकी तुलना में future जैसा लगता है

  • पहले कभी हमारी municipality apps में से एक को हमारे ownership में दिखाने के लिए Apple developer account set up करना पड़ा था
    बाकी apps के लिए जरूरत नहीं पड़ी थी, क्यों ऐसा था पता नहीं, लेकिन जो भी हो, करना पड़ा और experience काफी खराब था
    पहले Apple account चाहिए था, और मैं personal account इस्तेमाल नहीं करना चाहता था इसलिए work account नया बनाना पड़ा
    “organization account” नहीं बना सकते थे, इसलिए वह मेरे व्यक्ति से जुड़ गया, और शुक्र है कि एक पुराना iPhone था जिसे retire करने वाले थे, तो उसे इस्तेमाल कर सका
    इसके बाद Apple द्वारा मेरी identity verify करने का कई दिन इंतजार किया, जो असल में Apple का मेरे द्वारा boss के रूप में लिखे व्यक्ति को phone करके उससे यह कहलवाने की प्रक्रिया थी कि हाँ, यह वही है
    उम्मीद है उन्होंने और जांच की होगी, पर यकीन नहीं; और call करने वालों की English हमसे भी खराब थी, इसलिए कम से कम मामला हास्यास्पद तो था
    फिर payment set up करना पड़ा, क्योंकि किसी वजह से Apple developer account रखने के लिए पैसे देने पड़ते हैं
    60,000 आबादी वाले शहर के कुल budget में यह रकम शायद दिखे भी नहीं, लेकिन यह foreign subscription था और Apple ने local tax authority में आसानी से register हो सकने वाली B2B purchase method से process करने का तरीका नहीं दिया, इसलिए हर साल review का subject बन गया
    Payment भी सिर्फ credit card से हो सकता था, और organization card भी किसी actual व्यक्ति से जुड़ा होता है, इसलिए renewal संभालने के लिए कोई जिम्मेदार चाहिए
    लोग jobs बदलते हैं, और owner बदलने के लिए Apple और actual व्यक्ति के बीच contact होना पड़ता है, तो अंदाजा लगाया जा सकता है कि यह कितना मजेदार रहा होगा
    यह कुछ साल पहले की बात है, इसलिए बदल गया हो सकता है, लेकिन मैंने जिन 300 से ज्यादा enterprise IT solutions से deal किया है, उनमें Apple जितना भयानक कोई नहीं था
    निष्पक्ष होकर कहूँ तो मैं developer हूँ, यह काम मेरे पास क्यों आया पता नहीं, और IT operations side में शायद ऐसी चीज़ें ज्यादा common हों

    • अब शायद यह और खराब ही होगा। वे लगातार obstacles जोड़ रहे हैं ताकि लोग “ecosystem” में apps publish न कर सकें
      हाँ, अगर आप paperwork आसानी से handle कर सकने वाली बड़ी अमेरिकी company हैं, तो अलग बात है
    • अभी भी वही है। Developer account set up करते समय iPhone पर error loop में फँस गया, support team समझ ही नहीं पाई कि क्या हो रहा है, और लगभग 6 महीने बाद अचानक काम करने लगा
      अभी भी random है। तुरंत हो सकता है, या अगर bad luck से इस process के random bug में फँस गए तो लंबे समय तक fail होता रहेगा
    • मेरी जानकारी में governments और nonprofits को $99 Developer Program membership fee से छूट मिल सकती है
      यह कब शुरू हुआ, पता नहीं, लेकिन बहुत हाल की बात नहीं है
    • अगर आज किया जाए तो corporate purchasing के लिहाज से शायद काफी आसान हो सकता है। आजकल services के लिए अक्सर one-time-use virtual card numbers issue किए जाते हैं

  • कभी-कभी हम भूल जाते हैं कि मूल वेब/www कितना खुला था, और Apple और Google के कब्ज़े वाले “app ecosystem” की तुलना में आज भी कुल मिलाकर कितना खुला है
    बेशक “cloud” है, लेकिन सर्वर किराए पर लेकर अपनी चीज़ खुद होस्ट करने से कोई नहीं रोकता
    अगर बात न बने, तो उसे वहाँ से निकालकर दूसरा सर्वर किराए पर लिया जा सकता है। lock-in effect होता है और यह आसान न भी हो, पर असंभव नहीं है
    पूरे app ecosystem को देखें तो विकल्प सिर्फ 2 हैं, और सचमुच आप उनकी मेहरबानी पर निर्भर हैं
    निजी तौर पर मैं कभी भी अपना पूरा बिज़नेस एक “app” पर दांव पर नहीं लगाऊँगा। अगर audience सच में मांग करे तो एक छोटी सहायक चीज़ के रूप में app रख सकता हूँ, बस इतना ही
    मोबाइल डिवाइस पर जो products मुझे app इस्तेमाल करने के लिए मजबूर करते हैं, वे मुझे पसंद नहीं। बेहतर होगा m.website.com जैसा तरीका वापस आए, और मैं पूरे app ecosystem से बचना चाहूँगा

    • अगर वे 2 वही हैं जो मैं सोच रहा हूँ, तो उनमें से एक customer-support black hole है जिसके हाथ में निर्वासन का हथौड़ा है
      एक ही रात में, किसी भी वजह से या बिना वजह, आप “HN के front page पर मदद की भीख मांगने” की हालत में पहुँच सकते हैं
      दुआ है कि EU में sideloading की नई दिशा अमेरिका में भी वैसी ही मांग पैदा करे, लेकिन साथ ही मैं अच्छी तरह जानता हूँ कि यह तभी संभव है जब पर्याप्त लोग “walled garden” या “sideloading” का मतलब जानते हों और उसमें दिलचस्पी रखते हों

  • वेब सिद्धांत में शानदार है, लेकिन browser environment इतना सिर्फ basic चीज़ें देता है कि अगर आप Apple platforms जैसी batteries-included development experience के आदी हैं, तो app platform के रूप में यह बहुत आकर्षक नहीं लगता
    macOS पर शक्तिशाली और polished apps भी इतनी कम dependencies और sub-dependencies के साथ बनाए जा सकते हैं कि उन्हें एक हाथ पर गिना जा सके, और थोड़ी मेहनत से बिल्कुल बिना dependencies के भी
    इसके उलट समान स्तर की webapp में feature gaps भरने के लिए दर्जनों से सैकड़ों dependencies आ जाती हैं
    उदाहरण के लिए, मुझे समझ नहीं आता कि browser JavaScript का बिल्कुल उपयोग किए बिना या बहुत कम उपयोग करते हुए cells को efficiently reuse करने वाला built-in list/table view क्यों नहीं दे सकता
    सैकड़ों से हजारों items scroll कराते समय device को अटकने या memory खत्म होने से बचाना कोई दुर्लभ काम नहीं है
    AppKit, UIKit, SwiftUI, Android Framework, Compose, और शायद Flutter में भी यह बुनियादी रूप से अच्छी तरह संभल जाता है, लेकिन browser में इस बेहद basic feature के लिए library खींचनी पड़ती है या खुद code लिखना पड़ता है
    इसमें package management और overall tooling की समस्याएँ भी जोड़ दें, तो solutions आते-जाते रहते हैं लेकिन वही मूल समस्या लगातार बनी रहती है

    • मुझे Apple UI के लिए develop करने की तुलना में Electron के साथ development experience कहीं बेहतर लगता है
      15 साल पहले से iOS/iPad apps भी काफी बनाए हैं
      वेब की अच्छी बात यह है कि आम तौर पर आपकी जरूरत के हिसाब से कोई library या framework मिल जाता है। Electron इसका उदाहरण है
      Apple side पर अक्सर अच्छी libraries नहीं होतीं, और SwiftUI में bugs बहुत ज़्यादा हैं
      React बस ठीक से काम करता है और conceptually भी ज्यादा सरल है। two-way data binding एक खराब विचार है
      Apple को लगता है कि वह सब कुछ और सरल बना देता है, लेकिन असल में अक्सर चीज़ों को ज्यादा झंझटभरा और मुश्किल बना देता है
    • वेब को documents को ध्यान में रखकर बनाया गया था, इसलिए यह मानकर चलता है कि HTML file में दिखाने वाला सारा data पहले से मौजूद है
      table server पर जरूरी data और सही क्रम के साथ पहले से भरी हुई होती है
      इसलिए cells और rows को reuse करने की जरूरत नहीं पड़ती, और हजारों rows हों तब भी data KBs में होता है, इसलिए यह तेज़ चलता है
    • Flutter का अपना rendering engine है, इसलिए इसकी built-in API काफी मजबूत है
      WebAssembly और Flutter जैसे alternatives को देखते हुए browser की built-in capabilities की कमी अब समस्या नहीं रहनी चाहिए
    • मुझे समझ नहीं आता JavaScript में दिक्कत क्या है

  • मुझे नहीं लगता कि यह सच है कि developers Apple को कुछ नहीं देते
    अगर iPhone पर third-party apps न होते, तो Apple बहुत कम phones बेचता
    सिद्धांत रूप में कई apps वेब पर जा सकते हैं, लेकिन फिर भी third-party apps iPhone को मालिकाना हक रखने लायक कहीं अधिक बनाते हैं
    अगर सही मायने में competition हो, तो operating system makers developers को आकर्षित करने के लिए खूब मेहनत करते हैं। पुराने Ballmer के “developers developers developers” video को याद कर लें
    क्योंकि वे जानते हैं कि developers platform में value जोड़ते हैं और consumer choice को प्रभावित करते हैं
    आज की समस्या यह है कि meaningful competition नहीं है
    Apple के नियम चाहे जैसे हों, developers को iPhone के लिए कुछ देना ही पड़ता है, और Apple निश्चिंत रह सकता है कि किसी तीसरे mobile platform के जमने की संभावना बहुत कम है
    Apple यह जानता है, और कठोर policies के जरिए उसने हालात को बेरहमी से उलट दिया है
    developers iPhone को owning-worthy बनाने में बड़ी भूमिका निभाते हैं, फिर भी Apple ऐसा दिखाता है मानो वह उन्हें iPhone customers तक पहुँचने की अनुमति देकर कोई एहसान कर रहा हो, और उनकी पूरी revenue पर tax लगाता है
    यह market position का दुरुपयोग है, और blog जैसा कहता है, web के जरिए distribute करने के अलावा करने को बहुत कुछ नहीं है
    यह perfect नहीं है, लेकिन regulation के अलावा वही एक meaningful alternative है, और Apple के पास app developers पर tax लगाकर मिलने वाली अरबों dollar revenue को खुद छोड़ने की कोई वजह नहीं है, इसलिए वह regulation से बचने के लिए हर तरह की चाल चलेगा
    उम्मीद है कि web abusive app distribution rules से बचने के तरीके के रूप में ताकत पाएगा

  • मैं हर दिन सोचता हूँ कि web कितना शानदार है, और यह कितना अफसोसनाक है कि Apple ने developers को webapps के बजाय iOS apps बनाने के लिए प्रेरित करते हुए web को जितना हो सके उतना खराब करने की कोशिश की
    अगर App Store नहीं होता, तो web कहीं बेहतर होता
    content consumption, social media sources, algorithmic recommendations और digital experiences में कहीं ज्यादा diversity होती
    web हर जगह चलता है, और WebXR जैसी immersive/next-generation applications बनाने के लिए कई बेहतरीन APIs भी हैं
    लेकिन अगर कोई अपनी site पर WebXR app बनाए और उसे पैसे लेकर बेचे, तो Apple को उससे पैसा नहीं मिलता, इसलिए Apple ऐसे webapps को कभी promote नहीं करता
    लंबे समय में web नहीं मरेगा। कंपनियाँ आती हैं, मुनाफा निकालती हैं और चली जाती हैं, लेकिन web नहीं मरता

  • Apple प्लेटफ़ॉर्म डेवलपमेंट को आसान बनाने के लिए हज़ारों API देता है, उसने अपना programming language बनाया है जो प्लेटफ़ॉर्म के साथ अच्छी तरह integrate होता है, और दोनों के साथ काम करने वाला पूरी तरह integrated IDE भी है
    हाँ, “दोस्त”. जब तक तुम उनके प्लेटफ़ॉर्म के लिए develop नहीं कर रहे, उन्हें तुम्हारी परवाह नहीं है
    और उन्हें दोष कौन देगा? ऊपर की चीज़ें बेहद महंगे और बहुत समय लेने वाले निवेश हैं

    • इसमें यह बात छूट गई कि वे उन tools के अलावा लगभग हर चीज़ को lock down कर देते हैं
      Swift और Apple tools के बिना macOS पर सीधे app develop करने की कोशिश की थी, और वह बहुत दर्दनाक अनुभव था
      उन्होंने OpenGL को इस तरह खत्म करके version-freeze कर दिया कि इसे उनके अपने tools को push करने के अलावा समझाना मुश्किल है
      कोई external DLL load करना तक लगभग असंभव था
      Vulkan को Metal में बदलने की तरह, जो भी cross-platform है उसे Apple tools की व्यवस्था में नीचे उतरना पड़ता है
      macOS, सभी Linux distributions से भी ज़्यादा अजीब और special case है
      Windows development कितना आसान है, यह देखकर हैरानी होती है. Microsoft की तरफ़ लगभग सब कुछ cross-platform है
      जिन Apple चीज़ों का ज़िक्र किया गया है, उनमें से कोई भी platform-independent तरीके से काम करने नहीं देती
      वहीं Windows, DirectX जैसी अपनी technology को support करता है, लेकिन Vulkan, OpenGL आदि को सीधे चलाने की अनुमति भी देता है
    • Apple development को लेकर मैं भी काफ़ी positive हूँ और Xcode भी पसंद है. कम-से-कम SwiftUI के बाद से तो ऐसा है; Interface Builder तो मैं कभी सीख ही नहीं पाया
      लेकिन यह बात मायने रखती है कि लेखक एक music app पर काम करते हुए इसमें उतरा. Apple के audio API पूरी तरह बिखरे हुए हैं
      Media Player, AVPlayer, Core Audio, AVFoundation, AVAudioEngine आदि में NeXT के दौर तक पीछे जाती competing teams अपनी-अपनी libraries इस्तेमाल करती रहीं, और किसी तरह वे सब iPhone युग तक बच गईं लगती हैं
      COVID lockdown के दौरान Shoutcast/Icecast player बनाने की कोशिश में करीब तीन महीने लगाए, और वह सच में बहुत तकलीफ़देह था
    • Apple ने वे API सद्भावना से develop नहीं किए. वह lock-in strategy है
      उन्होंने iOS पर चलने वाला native cross-platform code लिखना प्रभावी रूप से असंभव बना दिया, और web apps native apps से compete न कर पाएं, इसके लिए राजनीतिक सीमाओं के भीतर जो कर सकते थे सब किया
    • उस कसौटी पर तो डर है कि Oracle आसानी से developers की सबसे ज़्यादा परवाह करने वाली company का विजेता बन जाएगा. आखिर उसने बहुत महंगे और लंबे समय वाले निवेश किए हैं
    • अपनी language बनाने की सचमुच ज़रूरत नहीं थी. वह भी lock-in effect का हिस्सा है

  • बड़े corporations को लेकर लेखक का स्वस्थ रवैया पसंद आया. यह आज के दौर की बुनियादी survival skill है
    अगर मेरे बस में हो तो iPhone या iPad पर कोई app install करने की ज़रूरत ही न पड़े, लेकिन platform restrictions के कारण व्यवहार में इसकी ज़रूरत पड़ जाती है
    मैंने देखा कि Safari में X/Twitter web app videos play नहीं करता, और X के लिए Lockdown Mode बंद करने के बाद भी ऐसा ही था
    जानना चाहूँगा कि यह platform mismatch बनाने के लिए Apple की गलती है या users से app install करवाने की X की मंशा
    मैं deep learning और LLM में specialize करता हूँ, लेकिन web development भी हमेशा enjoy किया है
    जो चीज़ रोड़े अटकाती है, वह है tools का बहुत ज़्यादा complex होना
    फिर भी मेरा एक जानकार ClojureScript + Dart के बारे में काफ़ी लिख रहा है, इसलिए सोच रहा हूँ एक बार try करूँ
    मैं ऐसा simple web app stack ढूँढना चाहता हूँ जिसे कुछ दिनों में सीखा जा सके और जिसका support अच्छा हो; अगर कोई recommendation हो तो अच्छा होगा

    • “perfect stack” खोजने वाली posts को ignore करना बेहतर है. perfect stack जैसी कोई चीज़ नहीं होती, और वास्तविक users को value देने वाला बढ़िया software ship करने के लिए यह ज़रूरी भी नहीं है
      web development का बड़ा हिस्सा browser को अच्छी तरह समझना है, और web.dev एक शानदार resource है
      उसके बाद React + TypeScript सीखना चाहिए. नया react.dev भी अच्छा है
      React perfect नहीं है, लेकिन UI बनाने के paradigm के तौर पर इतना अच्छा है कि Apple ने भी SwiftUI बनाते समय उससे प्रेरणा ली
      Vite उठाइए और coding शुरू कर दीजिए
      मेरी सबसे बड़ी recommendation यही होगी कि उन resources को ठीक से पढ़ें. documentation के पहले page से शुरू करके अंत तक धीरे-धीरे follow करना चाहिए
      हालांकि कुछ ही दिनों में बहुत कुछ सीख पाना मुश्किल है. front-end काम वाजिब कारणों से कठिन है