Apple ने मेरी dictation ऐप को Accessibility API का उपयोग करने के लिए अस्वीकार कर दिया
Mac App Store से एक macOS dictation ऐप को Accessibility API के उपयोग के कारण अस्वीकार किए जाने ने फिर से इस बहस को भड़का दिया है कि platforms को शक्तिशाली system permissions पर कितना नियंत्रण रखना चाहिए। टिप्पणीकार Apple के security और privacy तर्क—कि accessibility features पूरे machine पर प्रभावी नियंत्रण दे सकते हैं—को legitimate assistive और productivity tools पर पड़े प्रभाव के खिलाफ तौलते हैं, और असंगत rule enforcement तथा अस्पष्ट review standards की ओर इशारा करते हैं। चर्चा user choice, alternative distribution (direct downloads, Linux, EU app stores), और क्या Apple को अपनी broad Accessibility API को अधिक granular, consent-based capabilities से बदलना चाहिए, तक फैल जाती है.
App Store अस्वीकृति और Accessibility API
- ऐप के Mac App Store संस्करण को guideline 2.4.5 के तहत अस्वीकार कर दिया गया क्योंकि उसने Accessibility (AX) API का उपयोग करके synthesized keystrokes (CGEventPost) के जरिए अन्य ऐप्स में auto-paste किया।
- App Store का एक cut‑down संस्करण, जो केवल clipboard में लिखता है (कोई AX permission नहीं; उपयोगकर्ता Cmd+V दबाता है), स्वीकार कर लिया गया।
- full-featured संस्करण डेवलपर की साइट से सीधे वितरित किया जाता है, Apple द्वारा signed और notarized, इसलिए यह प्रतिबंध App Store-विशिष्ट है, पूरे OS पर नहीं।
- कुछ लोग इसी तरह के अनुभव बताते हैं: accessibility-based dictation या automation ऐप्स अक्सर macOS पर block हो जाते हैं, लेकिन कभी-कभी iOS पर pass हो जाते हैं, या इसके विपरीत, review outcomes असंगत होते हैं।
सुरक्षा, गोपनीयता, और Apple का तर्क
- कई टिप्पणीकार मानते हैं कि Apple Accessibility API की कड़ी निगरानी करके उचित है क्योंकि यह प्रभावी रूप से पूरे सिस्टम पर नियंत्रण दे देता है: keystrokes, cursor, screenshots, और cross-app data paths।
- चिंताओं में शामिल हैं कि malicious ऐप्स संवेदनशील फ़ील्ड्स में paste कर सकते हैं (जैसे बैंकिंग) या data exfiltrate कर सकते हैं। कुछ इस बात पर ज़ोर देते हैं कि भोले उपयोगकर्ता permissions बहुत आसानी से दे देंगे।
- अन्य लोग तर्क देते हैं कि उपयोगकर्ताओं को पहले से ही AX permissions स्पष्ट रूप से grant करनी होती हैं और उन्हें शक्तिशाली tools के लिए opt in करने दिया जाना चाहिए; पूरे वर्ग के apps पर प्रतिबंध overreach और संभवतः anti-competitive माना जाता है।
Accessibility API का डिज़ाइन
- कई टिप्पणियाँ API की आलोचना करती हैं कि यह अत्यधिक व्यापक है; यह apps को उससे अधिक power माँगने पर मजबूर करता है जितनी उन्हें वास्तव में चाहिए।
- एक प्रस्तावित समाधान: AX को संकीर्ण, अलग-अलग grant की जा सकने वाली क्षमताओं में बाँटना (जैसे paste, screenshot, cursor control) बजाय एक ही “superpower” permission के।
- प्रतिवाद: कुछ disabilities के लिए, एक interface के जरिए पूर्ण arbitrary control ही वास्तव में आवश्यक होता है, इसलिए इसे बाँटना assistive tech को सक्षम करना कठिन नहीं बनाना चाहिए।
Platforms, Walled Gardens, और Alternatives
- यह मामला closed ecosystems पर व्यापक बहस को हवा देता है। कुछ लोग इसे Apple के controlling, असंगत App Store regime का एक और उदाहरण मानते हैं और open platforms तथा side-loading के पक्ष में तर्क देते हैं।
- अन्य curated stores का समर्थन करते हैं, उन्हें सुरक्षा के लिए उपयोगी मानते हैं, और कहते हैं कि यदि उपयोगकर्ताओं को ये सीमाएँ पसंद नहीं हैं तो वे अलग OS चुन सकते हैं।
- कई लोग Linux desktops को flexible बताते हैं, जिनमें flatpaks, app stores, और अच्छा hardware support है, लेकिन साथ ही compatibility gaps (जैसे Microsoft Office, कुछ games) और कई users के लिए migration friction को स्वीकार करते हैं।
Workarounds, Business Impact, और Developer Strategy
- सुझावों में शामिल हैं:
- Mac App Store को अधिक सक्षम direct-download version के लिए “discovery + license anchor” की तरह मानना।
- एक सीमित/trial App Store build देना और स्टोर के बाहर अलग “pro” ऐप में upsell करना।
- कुछ लोग साझा करते हैं कि वे utilities के अलग “App Store-safe” और “full” versions बनाए रखते हैं, खासकर वे जो AX पर निर्भर हैं।
- अस्पष्ट और असंगत रूप से लागू किए गए नियमों को लेकर निराशा है, लेकिन व्यावहारिक स्वीकार्यता भी है: कई डेवलपर कई rejections की उम्मीद करते हैं और Apple की सीमाओं के आसपास design करना सीख लेते हैं।