App Store रिव्यू आपका ऐप लौटा देने के आठ कारण

संक्षिप्त उत्तर: App Store और Google Play पर ज़्यादातर ऐप रिजेक्शन किसी कोडिंग बग की वजह से नहीं होते। वे उन प्रशासनिक चीज़ों की वजह से होते हैं जिन पर डेवलपर का नहीं बल्कि बिज़नेस मालिक का नियंत्रण होता है — एक डेमो अकाउंट जिससे रिव्यूअर लॉग इन कर सके, एक पूरी प्राइवेसी पॉलिसी, असलियत से मेल खाता डेटा डिक्लेरेशन, कंपनी के नाम पर डेवलपर अकाउंट, और एक तकनीकी डेडलाइन जो पहले ही निकल चुकी है। इनमें से हर चीज़ लॉन्च से दो हफ़्ते पहले, कोड की एक भी लाइन लिखे बिना तैयार की जा सकती है।

शेड्यूल पर इसका असर जितना दिखता है उससे बड़ा है। रिजेक्शन का मतलब यह नहीं कि ऐप ख़राब है; इसका मतलब है कि हर सुधार के बाद ऐप कतार के आख़िर में लौट जाता है, और इस तरह किसी सीज़न या इवेंट से जुड़ा लॉन्च कैंपेन एक अनिश्चित देरी में बदल जाता है। इसीलिए पब्लिशिंग फ़ाइल को आख़िरी दिन के लिए छोड़ी गई कागज़ी कार्रवाई नहीं, बल्कि प्रोजेक्ट का हिस्सा माना जाना चाहिए।

1 — रिव्यूअर के पास आपका ऐप खोलने के लिए कोई डेमो अकाउंट नहीं है

लॉगिन स्क्रीन से शुरू होने वाले ऐप्स में यह सबसे ज़्यादा दोहराया जाने वाला कारण है। रिव्यूअर आपका ग्राहक नहीं है और आपके सिस्टम में उसका कोई फ़ोन नंबर रजिस्टर्ड नहीं है, इसलिए तैयार क्रेडेंशियल्स के बिना वह पहली स्क्रीन पर ही रुक जाता है। Apple का ऐप कम्प्लीटनेस नियम (App Completeness, 2.1) साफ़ है: फ़ाइनल वर्ज़न सबमिट करें, अगर आपके ऐप में लॉगिन है तो डेमो अकाउंट की जानकारी शामिल करें, और अपनी बैक-एंड सर्विस चालू रखें। अगर कानूनी या सुरक्षा दायित्व आपको असली अकाउंट देने से रोकते हैं, तो Apple की पूर्व मंज़ूरी के साथ आप एक बिल्ट-इन डेमो मोड शामिल कर सकते हैं जो ऐप की पूरी कार्यक्षमता दिखाए।

व्यवहार में: एक स्थायी अकाउंट तैयार करें जो एक्सपायर न हो और डेटा सफ़ाई के दौरान डिलीट न हो, और यह सुनिश्चित करें कि स्टेजिंग सर्वर पूरी रिव्यू अवधि में चल रहे हों, सिर्फ़ आपके ऑफ़िस के घंटों में नहीं।

2 — स्टोर आपके ऐप को दोबारा पैक की गई वेबसाइट मानता है

न्यूनतम कार्यक्षमता नियम (Minimum Functionality, 4.2) कहता है कि ऐप में ऐसे फ़ीचर, कंटेंट और UI होने चाहिए जो उसे दोबारा पैक की गई वेबसाइट से ऊपर उठाएँ, और जो ऐप मुख्य रूप से मार्केटिंग सामग्री, वेब क्लिपिंग, कंटेंट एग्रीगेटर या लिंक का संग्रह हैं, वे स्वीकार्य नहीं हैं। बहुत सी कंपनियाँ ऐप इसलिए माँगती हैं क्योंकि प्रतिस्पर्धी के पास एक है, और प्रोडक्ट एक खोल के अंदर वेबसाइट की नक़ल बनकर निकलता है।

बाहर निकलने के दो रास्ते हैं: या तो ऐप को ऐसी असली वैल्यू दें जो ब्राउज़र नहीं दे सकता — ऑफ़लाइन इस्तेमाल, ऑर्डर की स्थिति पर आधारित नोटिफ़िकेशन, बारकोड स्कैनिंग, डिवाइस पर सेव डेटा, पेमेंट और मैप इंटीग्रेशन — या स्टोर से गुज़रने के बजाय एक प्रोग्रेसिव वेब ऐप पब्लिश करें। हमने इस चुनाव पर प्रोग्रेसिव वेब ऐप या नेटिव ऐप में चर्चा की है।

3 — प्राइवेसी पॉलिसी अधूरी है या ऐप के अंदर मौजूद नहीं है

Apple का डेटा कलेक्शन नियम (Data Collection, 5.1.1) App Store Connect मेटाडेटा में और ऐप के अंदर किसी आसानी से मिलने वाली जगह पर प्राइवेसी पॉलिसी का लिंक माँगता है। पॉलिसी में यह बताना ज़रूरी है कि कौन सा डेटा इकट्ठा किया जाता है, कैसे, और उसका हर इस्तेमाल; यह पुष्टि करनी है कि जिस भी तीसरे पक्ष के साथ आप डेटा साझा करते हैं — एनालिटिक्स टूल, विज्ञापन नेटवर्क, थर्ड-पार्टी SDK — वह वही सुरक्षा देता है; और डेटा रखने व डिलीट करने की नीतियाँ तथा यूज़र अपनी सहमति कैसे वापस लेता है, यह समझाना है।

यह कोई पेज नहीं है जिसे आप किसी दूसरी वेबसाइट से कॉपी कर लें। यह इस बात का विवरण है कि आपका सिस्टम असल में क्या करता है, और इसे सऊदी व्यक्तिगत डेटा संरक्षण कानून (PDPL) के तहत आपके दायित्वों से मेल खाना चाहिए, जैसा कि हमने अपनी व्यावहारिक PDPL गाइड में समझाया है।

4 — ऐप के अंदर अकाउंट डिलीट करने का विकल्प नहीं है

नियम 5.1.1 (v) स्पष्ट है: अगर आपका ऐप अकाउंट बनाने की सुविधा देता है, तो आपको ऐप के अंदर अकाउंट डिलीट करने की सुविधा भी देनी होगी। यह एक ऐसा नियम भी जोड़ता है जिसे बहुत सी टीमें नज़रअंदाज़ कर देती हैं: अगर आपके ऐप में अकाउंट पर आधारित महत्वपूर्ण फ़ीचर नहीं हैं, तो लोगों को बिना लॉगिन इस्तेमाल करने दें, और व्यक्तिगत जानकारी तब तक न माँगें जब तक वह मुख्य कार्यक्षमता से सीधे संबंधित न हो या कानून द्वारा ज़रूरी न हो।

यहाँ अकाउंट डिलीट करना सिर्फ़ इंटरफ़ेस में एक बटन नहीं है; यह बैक-एंड में एक पूरा रास्ता है। ग्राहक के उन ऑर्डर, इनवॉइस और अकाउंटिंग रिकॉर्ड का क्या होगा जिन्हें कानूनी रूप से डिलीट नहीं किया जा सकता? आम जवाब है कि पहचान से जुड़े डेटा को वित्तीय रिकॉर्ड से डेवलपमेंट शुरू होने से पहले अलग कर दिया जाए, बाद में नहीं।

5 — Google Play का डेटा सेफ़्टी डिक्लेरेशन ऐप के असली काम से मेल नहीं खाता

Google हर डेवलपर से उस डेटा की घोषणा करने को कहता है जिसे ऐप इकट्ठा करता है और डिवाइस से बाहर भेजता है, थर्ड-पार्टी लाइब्रेरी और SDK द्वारा इकट्ठा किए गए डेटा सहित; साथ ही यह कि कलेक्शन ज़रूरी है या वैकल्पिक, उसका उद्देश्य, क्या डेटा ट्रांज़िट में एन्क्रिप्ट होता है, और क्या डिलीट करने के अनुरोध की कोई व्यवस्था है। पॉलिसी कहती है कि सही घोषणा की ज़िम्मेदारी अकेले डेवलपर की है, और उल्लंघन होने पर अपडेट ब्लॉक हो जाते हैं या ऐप Google Play से हटा दिया जाता है।

आम गलती सीधी-सी है: किसी डेवलपर ने अपना काम आसान करने के लिए एक एनालिटिक्स या क्रैश-रिपोर्टिंग टूल जोड़ दिया, और किसी ने उसे डिक्लेरेशन में शामिल नहीं किया। सबमिट करने से पहले अपनी टीम से एक ही सवाल पूछें — इस ऐप में थर्ड-पार्टी पैकेज की पूरी सूची क्या है, और उनमें से हर एक क्या भेजता है?

6 — अपडेट इसलिए रिजेक्ट होता है क्योंकि ऐप पुराने Android वर्ज़न को टारगेट करता है

31 अगस्त 2026 से Google Play यह माँग करता है कि नए ऐप और ऐप अपडेट Android 16 (API लेवल 36) या उससे ऊपर को टारगेट करें, कुछ अपवादों के साथ: Wear OS और Android Automotive के लिए लेवल 35, और Android TV तथा Android XR के लिए लेवल 34। जिन डेवलपर्स ने समय बढ़ाने का अनुरोध किया है, उनके पास 1 नवंबर 2026 तक का समय है।

बिज़नेस मालिक के लिए इसका व्यावहारिक नतीजा: आपका पब्लिश किया हुआ ऐप स्टोर में बना रहता है, लेकिन जब तक उसे ज़रूरी लेवल के हिसाब से दोबारा बिल्ड नहीं किया जाता, तब तक आप कोई भी अपडेट बिल्कुल जारी नहीं कर सकते — न कोई ज़रूरी सिक्योरिटी फ़िक्स, न कीमत में बदलाव। जो भी ऐप एक साल से अपडेट नहीं हुआ है, उसकी इस बिंदु पर जाँच ज़रूरी है, इससे पहले कि आपको कोई अर्जेंट रिलीज़ चाहिए हो।

7 — नए अकाउंट को पब्लिश करने से पहले 12 टेस्टर और 14 दिन चाहिए

Google Play पर 13 नवंबर 2023 के बाद बनाए गए पर्सनल डेवलपर अकाउंट सीधे पब्लिक में पब्लिश नहीं कर सकते। प्रोडक्शन एक्सेस के लिए आवेदन करने से पहले उन्हें एक क्लोज़्ड टेस्ट चाहिए जिसमें कम से कम 12 टेस्टर लगातार कम से कम 14 दिनों तक जुड़े रहें। यानी शेड्यूल में दो हफ़्ते और, और असली Google अकाउंट वाले 12 असली लोग।

दूसरी तरफ़, किसी संगठन के रूप में Apple Developer Program में नामांकन के लिए एक D-U-N-S नंबर और कॉन्ट्रैक्ट करने में सक्षम एक कानूनी इकाई चाहिए, संगठन के कानूनी नाम से — किसी ट्रेड नाम या ब्रांच के नाम से नहीं। नंबर लेने और वेरिफ़िकेशन पास करने में कई दिन लगते हैं। यह काम प्रोजेक्ट के पहले हफ़्ते में शुरू करें, लॉन्च वाले हफ़्ते में नहीं।

8 — स्टोर मेटाडेटा, स्क्रीनशॉट, और हर ब्रांच के लिए अलग ऐप

तीन छोटे नियम पूरी की पूरी रिलीज़ डुबो देते हैं: स्क्रीनशॉट में ऐप को इस्तेमाल होते हुए दिखाना ज़रूरी है, न कि टाइटल आर्ट, लॉगिन पेज या स्प्लैश स्क्रीन (2.3.3); ऐप का नाम 30 कैरेक्टर तक सीमित है और मेटाडेटा में ट्रेडमार्क वाले शब्द, लोकप्रिय ऐप्स के नाम या कीमतें ठूँसी नहीं जा सकतीं (2.3.7); और आप एक ही ऐप के कई bundle ID नहीं बना सकते (4.3a) — ठीक यही होता है जब कोई कंपनी हर ब्रांच या हर शहर के लिए अलग ऐप माँगती है। सही पैटर्न एक ही ऐप है जिसमें यूज़र ब्रांच चुनता है।

यह दरवाज़ा प्रोजेक्ट प्लान में कहाँ फ़िट होता है

  • डेवलपर अकाउंट अपनी कंपनी के नाम पर रजिस्टर करें, डेवलपर या एजेंसी के नाम पर नहीं। यह डोमेन की तरह ही कंपनी का एसेट है, जैसा कि हमने आपके सॉफ़्टवेयर के अधिकार किसके हैं में बताया है।
  • पहले हफ़्ते में ही अकाउंट खोलें: Apple हर साल 99 डॉलर लेता है और Google Play एक बार 25 डॉलर, और समय पेमेंट में नहीं बल्कि वेरिफ़िकेशन में लगता है।
  • कॉन्ट्रैक्ट में एक क्लॉज़ रखें जिसमें लिखा हो कि बिल्ड कौन सबमिट करेगा और रिव्यू नोट्स का जवाब कौन देगा, और कीमत में कितने रिव्यू चक्र शामिल हैं।
  • पब्लिशिंग फ़ाइल को एक अलग डिलीवरेबल मानें: प्राइवेसी पॉलिसी, डेटा डिक्लेरेशन, स्क्रीनशॉट, विवरण, डेमो अकाउंट, और थर्ड-पार्टी पैकेज की सूची।
कोड लॉन्च से एक हफ़्ता पहले पूरा हो जाता है। पब्लिशिंग फ़ाइल को दो हफ़्ते चाहिए। इस क्रम को गलत समझना ही ज़्यादातर देर से हुए लॉन्च की वजह है।

स्रोत