Apple में समस्या: अगर उपयोगकर्ता खुद ‘अभी भी ठीक नहीं हुआ’ की पुष्टि न करे, तो bug report मनमाने ढंग से बंद कर दी जाती है

 (lapcatsoftware.com)
1 पॉइंट द्वारा GN⁺ 2026-03-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Apple, Feedback Assistant के ज़रिए रिपोर्ट किए गए bug को तब अपने-आप बंद कर देता है जब उपयोगकर्ता खुद यह verify न करे कि “यह अभी तक ठीक नहीं हुआ है”
  • network filter extension से जुड़ा privacy leak bug (FB12088655), जिस पर 3 साल तक कोई जवाब नहीं आया, उसके बारे में Apple ने अचानक पुष्टि मांगी और कहा कि 2 हफ्ते में जवाब न मिलने पर इसे ठीक मान लिया जाएगा
  • लेकिन Little Snitch developers ने पुष्टि की कि वही समस्या नए macOS में भी बनी हुई है, फिर भी Apple ने report बंद कर दी
  • यह प्रक्रिया bug report की संख्या को कृत्रिम रूप से कम करने वाली संरचना की तरह काम करती है, जिससे वास्तविक quality समस्याएं छिप जाती हैं
  • नतीजतन, Apple का bug management तरीका developers के भरोसे को कमजोर करता है और collaborative feedback culture को नुकसान पहुंचाता है

Apple की bug report auto-close समस्या

  • Apple Feedback Assistant के ज़रिए bug report करने वाले एक developer ने Apple की उस प्रथा की आलोचना की, जिसमें कंपनी उपयोगकर्ता की पुष्टि के बिना मनमाने ढंग से report बंद कर देती है
    • Apple, अगर उपयोगकर्ता खुद यह पुष्टि नहीं करता कि “bug अभी तक ठीक नहीं हुआ”, तो उस report को अपने-आप बंद कर देता है
    • कई साल तक कोई जवाब नहीं आता, फिर अचानक verification request भेजी जाती है, और 2 हफ्तों में जवाब न मिलने पर उसे “fix हो चुका” मान लिया जाता है
  • मार्च 2023 में जमा की गई FB12088655 “Privacy: Network filter extension TCP connection and IP address leak” case में, 3 साल तक कोई जवाब नहीं आया और मार्च 2026 में जाकर Apple ने macOS 26.4 beta 4 में verification मांगा
    • beta OS हमेशा install न होने की वजह से इसकी पुष्टि करना मुश्किल था, और Apple से fix की स्थिति पूछने पर भी कोई स्पष्ट जवाब नहीं मिला
    • Apple ने सूचित किया कि “अगर 2 हफ्तों के भीतर पुष्टि नहीं की गई, तो इसे fix मानकर report बंद कर दी जाएगी”
    • Little Snitch developers ने रिपोर्ट किया कि macOS 26.4 beta 4 में भी वही समस्या reproduce हो रही है
    • वास्तव में macOS 26.4 के release version में भी वही bug मौजूद था
  • यह कहा गया कि Apple का unpatched bug के लिए उपयोगकर्ता से सीधे verification मांगना अप्रभावी और अव्यवहारिक प्रक्रिया है
    • यह भी उल्लेख हुआ कि अंदरूनी तौर पर bug report की संख्या कम करने के लिए incentive structure काम कर रहा हो सकता है
    • इसकी वजह से “open bugs” की संख्या कम दिखती है और internal metrics पर quality बेहतर दिखाई दे सकती है

अन्य bug report cases

  • एक और case के रूप में FB22057274 “Pinned tabs: slow-loading target="_blank" links appear in the wrong tab” bug का उल्लेख हुआ
    • 100% reproduce होने वाली समस्या होने के बावजूद, Apple ने इसे “Investigation complete - Unable to diagnose with current information” के रूप में चिह्नित किया
    • 9 मार्च को अतिरिक्त जानकारी मांगी गई, लेकिन Apple ने जवाब नहीं दिया
  • iPadOS 26.4 beta में Safari crash bug नया सामने आया, और Apple ने इसे public release से पहले ठीक नहीं किया
    • लेखक ने आलोचना करते हुए कहा कि “ऐसा लगता है कि beta का उद्देश्य bugs को ठीक करना नहीं, बल्कि bug report करने वालों को परेशान करना है”

Hacker News के बाद हुए बदलाव और Apple की प्रतिक्रिया

  • यह लेख Hacker News के पहले पेज पर पहुंचने के तुरंत बाद Apple ने FB22057274 report को update किया
    • Apple ने UI समस्या के लिए sysdiagnose log submit करने को कहा
    • जबकि reproduction steps और screen recording video पहले ही दिया जा चुका था, और यह कहा गया कि sysdiagnose privacy risk पैदा करता है और अनावश्यक सामग्री है
  • लेखक ने Apple की मांग के जवाब में यह कहा
    • “UI bug के लिए sysdiagnose की जरूरत नहीं है और यह मददगार भी नहीं है”
    • Little Snitch के बिना भी reproduce करने का तरीका बताते हुए कहा गया कि Xcode Additional Tools के Network Link Conditioner में uplink delay 3000ms profile सेट करने पर वही समस्या फिर से दिखाई देती है

Xcode Additional Tools गाइड

  • Xcode Additional Tools में कई उपयोगी utilities शामिल हैं, Apple Developer Downloads page (login required) से इन्हें डाउनलोड किया जा सकता है

समग्र मूल्यांकन

  • Apple का bug report management तरीका developers पर अनावश्यक बोझ डालता है, और यह वास्तविक समस्या समाधान से ज्यादा reports की संख्या घटाने पर केंद्रित संरचना की तरह काम करता है
  • लंबे समय तक बिना जवाब वाली reports, अव्यवहारिक verification मांग, और अप्रभावी information request जैसी चीजों के कारण developers का भरोसा और सहयोग की इच्छा कमजोर हो रही है

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

1 टिप्पणियां

 
GN⁺ 2026-03-27
Hacker News की राय

  • लगता है कि लेखक ने enterprise software का अनुभव नहीं किया है
    जब डेवलपर को bug report मिलती है, तो “इसे reproduce नहीं कर पा रहे, क्या आपने latest version में check किया?” कहकर कुछ किए बिना समय निकालना एक आम तरीका है
    अगर पुष्टि न हो पाए, तो उसे “user error” या “cannot reproduce” कहकर बंद कर दिया जाता है
    इसका एकमात्र जवाब अक्सर यही होता है कि “हाँ, मैंने check किया” कहो, जबकि वास्तव में check न किया हो

    • मैंने Microsoft paid support इस्तेमाल किया है, और वे हमेशा evidence submit करने को कहते हैं
      अगर logs में antivirus दिख जाए, तो “उधर पूछिए” कहकर तुरंत बंद कर देते हैं
    • अंदर की स्थिति देखें तो यह बदनीयती से ज़्यादा cost-efficiency का मामला है
      क्योंकि एक user द्वारा उठाए गए bug से भी ज़्यादा महत्वपूर्ण कई business priorities होती हैं
      फिर भी user के नज़रिए से यह दुखद है
    • open source में भी बिल्कुल यही होता है. stalebot पुराने issues अपने-आप बंद कर देता है
    • मैंने ऐसे reproduction GIF अच्छी तरह बनाना सीख लिया है जिन्हें सीधे email में डाला जा सके
      ज़्यादातर developers या तो अपने product को test करना नहीं जानते, या फिर करने में आलस करते हैं
    • मैंने दोनों पक्षों का अनुभव किया है
      enterprise tech support के समय मुझे रोज़ कम-से-कम दो नए cases लेने पड़ते थे, और 20 से ज़्यादा cases एक साथ संभालता था
      जिन cases में कोई प्रगति नहीं होती थी, उन्हें “inactive closure” के रूप में बंद करते समय बहुत राहत मिलती थी
      बाद में बंद करने से पहले तीन बार संपर्क करने का नियम आ गया, जो किसी बुरे सपने जैसा था
      आखिरकार बड़ी कंपनियों की bureaucracy सब कुछ खराब कर देती है

  • Apple का रवैया ऐसा लगता है जैसे वह bug के अपने-आप गायब हो जाने की दुआ कर रहा हो
    अब मैं भी bug reports भेजता ही नहीं हूँ
    मुझे ignore किया जाना ठीक है, लेकिन समस्या तब है जब वे मुझे unpaid QA staff की तरह ट्रीट करते हैं
    bug के अस्तित्व को साबित करने के लिए बहुत ज़्यादा मेहनत माँगते हैं

    • Microsoft भी ऐसा ही है, खासकर Azure या 365 से जुड़े issues में
      सोच यह रहती है कि “यह तुम्हारा software है, debugging भी तुम ही करो”

  • open source projects भी इसी तरह stale issues auto-close करते हैं
    एक तय समय के बाद अपने-आप यह मान लेना कि issue solve हो गया है, बेतुका है

    • maintainer के नज़रिए से priorities अलग हो सकती हैं
      open source का फायदा यह है कि आप खुद fix कर सकते हैं, PR submit कर सकते हैं, या fork करके हल निकाल सकते हैं
    • अगर stalebot बंद करने के बजाय सिर्फ stale label लगाए, तो वह ठीक है
      पुराने tickets को filter करना ज़्यादा तर्कसंगत है

  • user के नज़रिए से यह चिढ़ाने वाला है, लेकिन हर bug आसानी से reproduce नहीं होता
    कभी-कभी संबंधित code changes के बाद user से दोबारा test करवाना ज़्यादा efficient होता है
    फिर भी पुराने, executable न होने वाले bugs को बंद करते समय मन असहज रहता है

    • पहले मैंने Mac को ActiveDirectory से जोड़ने का काम किया था, और Apple का आम जवाब था “works on 17!”
      उसका मतलब बस इतना होता था कि Apple के अंदरूनी network में वह reproduce नहीं हुआ
    • कुछ लोगों का यह भी कहना है कि “इसे बस खुला क्यों नहीं छोड़ देते?”
      बंद करना सिर्फ समस्या को छिपाना है, और खुला रखने में कोई लागत नहीं लगती
    • Apple “cannot reproduce” भी नहीं कहता और “fixed” भी नहीं, बस इतना कहता है कि “macOS 26.4 beta 4 में check कीजिए”
      beta install करना user के लिए कहीं ज़्यादा अक्षम है
      मैंने Xcode sample project और reproduce करने के steps तक दिए थे
      मुझे पूरा यकीन है कि Apple ने कुछ भी नहीं किया
      शायद WWDC से पहले macOS 27 की तैयारी में bug cleanup show चल रहा है
    • Apple जैसी कंपनी के पास ऐसा tool होना चाहिए जो system state को पूरी तरह capture करके reproduce कर सके

  • Facebook और Google में काम करते समय मैंने bug management tricks बहुत देखी हैं
    SLA आने के बाद bug priority को कृत्रिम रूप से घटाना, या “क्या यह अब भी समस्या है?” कहकर user पर डाल देना आम था
    समय बीत जाने पर “वह version अब obsolete है” कहकर बंद कर देते थे
    यहाँ तक कि जिम्मेदारी से बचने के लिए उसे किसी दूसरे bug के साथ ज़बरदस्ती merge भी कर देते थे
    आखिरकार यह सब organization metrics (SLA) की वजह से होता है
    इसलिए अब मैं bug reports लगभग नहीं करता

    • engineers सच में bugs fix करना चाहते हैं
      लेकिन management कहता है, “अभी AI projects पर focus करो”
      और फिर वही लोग डाँटते हैं कि “bugs बहुत ज़्यादा हैं”
    • मैंने भी p2/s2 को p3/s3 में downgrade किया है
      बंद करने की बजाय बस ignore कर देना मुझे ज़्यादा ईमानदार लगता है
      leadership इसी तरह की forced triage को बढ़ावा देती थी
      automatic notifications को रोकना एक समस्या है
    • priority और severity को अलग रखने की वजह यह है
      मसलन, अगर site पूरी तरह down हो, तब भी off-season होने पर वह अभी P0 न हो
      लेकिन व्यवहार में data quality इतनी खराब होती है कि reporting के काम नहीं आती
      इसलिए एक single priority value ज़्यादा practical है
      ऐसे ignore किए गए issues को stalebot मानो उनकी जगह बंद कर देता है
    • जिस बड़ी कंपनी में मैं था, वहाँ भी ऐसा ही था
      customer-facing severity और internal priority अलग-अलग manage किए जाते थे
      Salesforce “Lightning Experience” नाम के उलट बहुत धीमा है
      अंदरूनी tools कहीं ज़्यादा तेज़ और efficient थे
    • यह सब principal-agent problem का एक क्लासिक उदाहरण है

  • ElevenLabs में भी यही हुआ था
    bug report डालो, AI अपने-आप जवाब दे देता था, और 48 घंटे बाद stale कर दिया जाता था

    • ElevenLabs के एक कर्मचारी ने आकर बताया कि “अगर GitHub open source repository में submit करें, तो इंसान सीधे जवाब देता है”

  • लगता है कि जल्द ही LLM agents इस समस्या को हल कर देंगे
    वे अपने-आप “यह अभी तक ठीक नहीं हुआ” जैसी comment डालेंगे, और समय-समय पर “यह एक महत्वपूर्ण workflow को प्रभावित कर रहा है” कहकर automatic bump भी कर सकेंगे

    • अगर maintainer issue बंद कर दे, तो agent अपने-आप आलोचनात्मक blog post भी डाल सकता है

  • मैंने पहले Microsoft को एक bug submit किया था, और कुछ महीनों बाद “cannot reproduce” का संदेश मिला
    असल में इस बीच किसी दूसरे fix से वह परोक्ष रूप से ठीक हो गया था
    तब मुझे एहसास हुआ कि मैं हाथी का एक हिस्सा छूने वाला अंधा था

  • मैं Apple का पूर्व कर्मचारी हूँ
    Apple का internal bug tracker Radar कहलाता है, और हर issue को बंद करने से पहले “Verify” stage से गुजरना होता है
    ऊपर से यह quality assurance process लगता है, लेकिन वास्तव में बहुत से Radar हमेशा के लिए Verify state में अटके रहते हैं
    teams का मूल्यांकन “unverified Radar की संख्या” से होता है, इसलिए कुछ समय बाद उन्हें ज़बरदस्ती बंद कर दिया जाता है

    • ज़्यादातर teams Verify को practically Closed state की तरह इस्तेमाल करती हैं
      “0 bugs” का भ्रम विकृत performance metrics पैदा करता है
    • समाधान यह है कि “reopened bugs की संख्या” को भी साथ में मापा जाए
    • Feedback Assistant का “latest beta में check कीजिए” वाला संदेश Radar की Verify state से अलग चीज़ है
      इससे यह मानना मुश्किल है कि Apple engineer ने सच में fix करने की कोशिश की थी

  • कंपनी में सहकर्मियों के साथ backlog cleanup meeting करते हुए
    हमने पुराने one-off bugs को साफ किया था
    ऐसी process बहुत आम है