App Store रिजेक्शन 2.1 App Completeness: दोबारा सबमिट करने से पहले रिलीज़ बिल्ड का टेस्ट प्लान (2026)

2.1 App Completeness के तहत App Store रिजेक्शन का मतलब है कि रिव्यूअर आपके ऐप को एक ग्राहक की तरह इस्तेमाल नहीं कर पाया। हो सकता है ऐप क्रैश हुआ हो, प्लेसहोल्डर कंटेंट दिखा हो, रिव्यूअर लॉगिन स्क्रीन पर अटक गया हो या कोई इन-ऐप खरीदारी छिपी रही हो। इसका फ़िक्स शायद ही कभी कोड की एक लाइन होता है। दोबारा सबमिट करने से पहले रिलीज़ बिल्ड पर एक छोटा टेस्ट प्लान चलाएँ, फ्रेश इंस्टॉल और उन्हीं क्रेडेंशियल्स के साथ जो आप App Review को देते हैं। यह पोस्ट उस प्लान को स्टेप-बाय-स्टेप समझाती है और दिखाती है कि दूसरे डेवलपर्स ने यही रिजेक्शन कैसे ठीक किया।

App Store गाइडलाइन 2.1 App Completeness क्या जाँचती है?

गाइडलाइन 2.1 जाँचती है कि आपका सबमिट किया गया बिल्ड एक पूरा, काम करता ऐप है। इसमें पूरा metadata, काम करते लिंक, डेमो लॉगिन, लाइव बैक एंड, और ऐसी इन-ऐप खरीदारी होनी चाहिए जिसे रिव्यूअर ढूँढ और इस्तेमाल कर सके।

Apple की App Review Guidelines 2.1 को दो हिस्सों में बाँटती हैं। 2.1(a) कहती है कि सबमिशन “सभी ज़रूरी metadata और पूरी तरह काम करते URL के साथ फ़ाइनल वर्ज़न होने चाहिए” और प्लेसहोल्डर टेक्स्ट व खाली वेबसाइटें हटा दी जानी चाहिए। यह बग और स्थिरता के लिए डिवाइस पर टेस्ट करने को भी कहती है, और “अगर आपके ऐप में लॉगिन है तो डेमो अकाउंट की जानकारी शामिल करें (और अपनी बैक-एंड सर्विस चालू रखें!)।” Apple “अधूरे app bundle और ऐसी बाइनरी को रिजेक्ट करेगा जो क्रैश होती हैं या साफ़ तकनीकी समस्याएँ दिखाती हैं।” 2.1(b) कहती है कि इन-ऐप खरीदारी “पूरी, अप-टू-डेट, रिव्यूअर को दिखने वाली और काम करने वाली” होनी चाहिए। अगर कॉन्फ़िगर की गई कोई खरीदारी ऐप में नहीं मिलती, तो अपने review notes में इसकी वजह बताएँ।

यह रिजेक्शन आम है। Apple के Preparing for App Review पेज के अनुसार: “औसतन, 40% से ज़्यादा अनसुलझी समस्याएँ गाइडलाइन 2.1: App Completeness से जुड़ी होती हैं, जिसमें क्रैश, प्लेसहोल्डर कंटेंट, अधूरी जानकारी और भी बहुत कुछ शामिल है।”

डीबग बिल्ड टेस्ट करने से 2.1 की समस्याएँ क्यों नहीं पकड़ में आतीं?

डीबग बिल्ड उस तरह नहीं चलता जैसे रिव्यूअर की कॉपी चलेगी। रिव्यूअर एक साफ़ डिवाइस पर distribution-signed रिलीज़ बिल्ड इंस्टॉल करता है, जिसमें न कोई सेव्ड सेशन होता है और न कोई डीबग शॉर्टकट।

आपका सिम्युलेटर पहले से साइन इन है। आपका लोकल API शायद ऐसे staging सर्वर की ओर इशारा करता है जो कभी डाउन नहीं होता। डीबग फ़्लैग paywall को स्किप कर देते हैं, और feature flags डिफ़ॉल्ट रूप से ऑन रहते हैं। रिव्यूअर को इनमें से कुछ नहीं मिलता। Apple का रिव्यू पेज यह भी कहता है कि “लेटेस्ट सॉफ़्टवेयर वाले डिवाइस पर अच्छी तरह टेस्ट करें”, इसलिए हो सकता है रिव्यूअर आपके टेस्ट फ़ोन से नए iOS पर हो।

TestFlight रिव्यूअर के सेटअप के सबसे क़रीब है। TestFlight overview के अनुसार, आप अपनी App Store Connect टीम से 100 तक internal testers और 10,000 तक external testers जोड़ सकते हैं। आप किसी बिल्ड को 90 दिनों तक टेस्ट कर सकते हैं। ठीक वही बिल्ड अपलोड करें जो आप सबमिट करना चाहते हैं, उसे TestFlight से ऐसे डिवाइस पर इंस्टॉल करें जिस पर ऐप कभी नहीं चला, और उसी कॉपी को टेस्ट करें।

दोबारा सबमिट करने से पहले रिलीज़ बिल्ड टेस्ट प्लान में क्या-क्या होना चाहिए?

रिलीज़ बिल्ड टेस्ट प्लान हर उस जगह को जाँचता है जहाँ एक नया रिव्यूअर अटक सकता है: लॉन्च, permissions, लॉगिन, बैक एंड, कंटेंट, लिंक, खरीदारी, नेटवर्क फ़ेलियर और iPad। TestFlight बिल्ड पर ये स्टेप्स क्रम से चलाएँ और हर नतीजा नोट करें, ताकि आप उसे अपने review notes में लिख सकें।

1. लेटेस्ट iOS पर क्लीन इंस्टॉल। पुरानी कॉपी डिलीट करें, TestFlight से इंस्टॉल करें और बिना किसी सेव्ड स्टेट के लॉन्च करें। तीन बार cold launch करें और पक्का करें कि onboarding क्रैश नहीं होता।
2. हर permission प्रॉम्प्ट को एक बार मना करें। नोटिफ़िकेशन, लोकेशन, कैमरा और ट्रैकिंग को अस्वीकार करें। ऐप फिर भी किसी इस्तेमाल लायक स्क्रीन तक पहुँचना चाहिए। साथ ही पक्का करें कि ऐप या उसके SDK जिन भी protected resources का इस्तेमाल करते हैं, उन सबके लिए Info.plist में usage description है।
3. ठीक उन्हीं डेमो क्रेडेंशियल्स से साइन इन करें। उन्हें App Store Connect से कॉपी करें, अपने पासवर्ड मैनेजर से नहीं। अकाउंट में वास्तविक जैसा डेटा होना चाहिए, उसे ईमेल वेरिफ़िकेशन की ज़रूरत नहीं होनी चाहिए, और उसमें आपके अपने फ़ोन से जुड़ा two-factor authentication नहीं होना चाहिए।
4. पक्का करें कि बैक एंड प्रोडक्शन है और लाइव है। बिल्ड को प्रोडक्शन endpoints की ओर इशारा करना चाहिए। rate limits, IP allowlists और geo-blocking से रिव्यूअर लॉक आउट नहीं होना चाहिए। गाइडलाइन 2.1(a) कहती है कि अपनी बैक-एंड सर्विस चालू रखें।
5. हर टैब और स्क्रीन देखें। lorem ipsum, “Coming soon” स्क्रीन, बिना किसी जानकारी वाले खाली स्टेट, टेस्ट इमेज और कुछ न करने वाले बटन ढूँढें।
6. हर लिंक पर टैप करें। इसमें privacy policy, support, terms और सभी web views शामिल हैं। Apple कहता है: “सभी ऐप्स के लिए अप-टू-डेट संपर्क जानकारी वाला यूज़र सपोर्ट लिंक और आपकी privacy policy का लिंक ज़रूरी है।”
7. हर इन-ऐप खरीदारी खोलें। नए अकाउंट से साइन इन करें। जाँचें कि वर्ज़न के साथ सबमिट किया गया हर प्रोडक्ट क़ीमत के साथ दिखता है, sandbox में ख़रीदा जा सकता है, और Restore Purchases काम करता है।
8. धीमे या टूटे नेटवर्क पर टेस्ट करें। किसी फ़्लो के बीच में airplane mode चालू करें। साफ़ error मैसेज ठीक है। कभी न रुकने वाला spinner या क्रैश ठीक नहीं है।
9. अगर आप iPad सपोर्ट करते हैं तो उसे जाँचें। अगर ऐप iPad पर चलता है, तो वहाँ लॉन्च करें और पक्का करें कि लेआउट यूज़र को फँसाता नहीं।

स्टेप 3 का डेमो अकाउंट किसी भी दूसरे स्टेप से ज़्यादा बार-बार रिजेक्शन की वजह बनता है। App Store review डेमो अकाउंट सेट अप करने की हमारी गाइड बताती है कि लंबे समय तक चलने वाला अकाउंट कैसे बनाएँ।

2.1 रिजेक्शन मैसेज से सही फ़िक्स कैसे पहचानें?

2.1 रिजेक्शन का फ़िक्स पहचानने के लिए गाइडलाइन नंबर के बाद वाला वाक्य पढ़ें। उसमें लक्षण लिखा होता है, और हर लक्षण टेस्ट प्लान के किसी एक स्टेप की ओर इशारा करता है।

मान लीजिए एक habit-tracking ऐप इस मैसेज के साथ रिजेक्ट होता है: “We were unable to review the app because it crashed on launch” (हम ऐप का रिव्यू नहीं कर पाए क्योंकि वह लॉन्च पर क्रैश हो गया)। दूसरे नोट में लिखा है कि रिव्यूअर इन-ऐप खरीदारी नहीं ढूँढ पाया। नीचे दी गई टेबल आम लक्षणों को वजह, टेस्ट और फ़िक्स से जोड़ती है।

किसी भी रिजेक्शन मैसेज को पढ़ने के व्यापक तरीक़े के लिए देखें App Store रिजेक्शन: गाइडलाइन के हिसाब से इसे कैसे ठीक करें।

दूसरे डेवलपर्स के 2.1 रिजेक्शन कैसे दिखते थे?

सार्वजनिक 2.1 केस एक ही पैटर्न पर चलते हैं। ऐप डेवलपर के सेटअप पर चलता है और रिव्यूअर के लिए फ़ेल हो जाता है, किसी ऐसी चीज़ की वजह से जो सिर्फ़ फ्रेश इंस्टॉल या किसी अनजान व्यक्ति के लॉगिन से सामने आती है।

• छूटे usage description से क्रैश। Solar2D फ़ोरम पर एक डेवलपर को iOS 18.3.2 वाले iPhone 13 mini पर बताया गया: “We were unable to review the app because it crashed on launch”, जबकि ऐप TestFlight में चल रहा था। एक दूसरे सदस्य को अटैच किए गए क्रैश लॉग में यह मिला: “This app has crashed because it attempted to access privacy-sensitive data without a usage description.” (यह ऐप इसलिए क्रैश हुआ क्योंकि इसने usage description के बिना प्राइवेसी-संवेदनशील डेटा एक्सेस करने की कोशिश की)। डेवलपर ने बताया, “It passed after adding : NSUserTrackingUsageDescription.” (NSUserTrackingUsageDescription जोड़ने के बाद यह पास हो गया)।
• सोशल लॉगिन जिन्हें रिव्यूअर इस्तेमाल नहीं कर सका। Apple Developer Forums पर एक डेवलपर ने बार-बार 2.1 रिजेक्शन की शिकायत की, क्योंकि रिव्यूअर “सोशल लॉगिन इस्तेमाल नहीं कर पाए।” उन्होंने Apple और Google डेमो अकाउंट दिए थे, लेकिन Apple ID साइन-इन के लिए डेवलपर के फ़ोन पर भेजा गया वेरिफ़िकेशन कोड चाहिए था। Apple स्टाफ़ ने जवाब दिया कि App Review उनसे सीधे संपर्क करेगा। कोई सार्वजनिक फ़िक्स पोस्ट नहीं किया गया।
• इन-ऐप खरीदारी “सबमिट की गई बाइनरी में नहीं मिली।” एक RevenueCat community thread में एक डेवलपर का ऐप इसलिए रिजेक्ट हुआ क्योंकि मंथली प्लान बाइनरी में नहीं मिला, जबकि sandbox खरीदारी काम कर रही थी। एक मददगार ने बताया कि ऐसा ही एक रिजेक्शन paywall तक पहुँचने के हर रास्ते के विस्तृत walkthrough और स्क्रीनशॉट्स के साथ जवाब देकर सुलझा था। RevenueCat स्टाफ़ ने सलाह दी कि हर सबमिट किया गया प्रोडक्ट डिफ़ॉल्ट paywall पर दिखाएँ और StoreKit टेस्ट फ़ाइलों को Archive scheme से बाहर रखें।

तीनों मामलों में डेवलपर की अपनी टेस्टिंग पास हो गई थी। फ़ेलियर सिर्फ़ रिव्यूअर की शुरुआती स्थिति से दिखा: न 2FA वाला फ़ोन, न पिछला सेशन और न यह जानकारी कि paywall कहाँ है। ऊपर दिया गया टेस्ट प्लान ठीक इसी शुरुआती स्थिति को दोबारा बनाता है।

2.1 रिजेक्शन के बाद App Review notes में क्या लिखना चाहिए?

2.1 रिजेक्शन के बाद review notes में काम करते डेमो क्रेडेंशियल्स होने चाहिए, रिजेक्ट हुए बिल्ड के बाद क्या बदला उसकी सूची होनी चाहिए, और साफ़ लिखा होना चाहिए कि इन-ऐप खरीदारी और कोई भी कम स्पष्ट फ़ीचर कहाँ मिलेंगे।

Apple का रिव्यू पेज कहता है कि अकाउंट की जानकारी और ख़ास कॉन्फ़िगरेशन App Review Information सेक्शन में डालें। अगर किसी फ़ीचर के लिए ऐसा हार्डवेयर या एनवायरनमेंट चाहिए जिसे सेट अप करना मुश्किल है, तो “डेमो वीडियो या हार्डवेयर देने के लिए तैयार रहें।” गाइडलाइन 2.3.1(a) यह भी जोड़ती है कि नए फ़ीचर्स को Notes for Review में “स्पष्ट रूप से” बताया जाना चाहिए, और “सामान्य विवरण रिजेक्ट कर दिए जाएँगे।” एक छोटा, व्यवस्थित नोट अच्छा काम करता है:

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

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

2.1 रिजेक्शन के बाद दोबारा सबमिट या अपील कैसे करें?

2.1 रिजेक्शन के बाद दोबारा सबमिट करने के लिए, टेस्ट किया हुआ बिल्ड अपलोड या सिलेक्ट करें, App Store Connect में App Review को बताएँ कि आपने क्या बदला, review notes अपडेट करें और फिर से सबमिट करें। अपील सिर्फ़ तभी करें जब आपको लगे कि रिव्यूअर ने ऐप को ग़लत समझा।

1. जाँचें कि App Store Connect में वर्ज़न से जुड़ा बिल्ड नंबर उसी TestFlight बिल्ड से मेल खाता है जिसे आपने टेस्ट किया।
2. रिजेक्शन मैसेज का जवाब हर फ़िक्स के छोटे सारांश के साथ दें। खरीदारी या नेविगेशन की समस्या के लिए स्टेप-बाय-स्टेप निर्देश और स्क्रीनशॉट्स जोड़ें।
3. App Review Information सेक्शन को मौजूदा क्रेडेंशियल्स और notes के साथ अपडेट करें।
4. रिव्यू के लिए सबमिट करें। अक्टूबर 2026 तक, Apple के अनुसार वह आमतौर पर “कम से कम 50% सबमिशन 24 घंटे से कम में और 90% सबमिशन 48 घंटे से कम में” रिव्यू करता है।

अगर आपको लगता है कि Apple से ग़लती हुई है, तो App Review पेज से आप App Review Board में अपील कर सकते हैं। ठोस कारण बताएँ कि ऐप नियमों का पालन क्यों करता है, और “रिव्यू में पास न होने वाले हर सबमिशन के लिए सिर्फ़ एक अपील करें।” फिर भी, 2.1 रिजेक्शन के मामले में बहस करने की बजाय साफ़ डिवाइस पर समस्या को दोहराना आमतौर पर ज़्यादा तेज़ होता है। अगर आप दोबारा सबमिशन का काम किसी और को सौंपना चाहते हैं, तो हमारी App Store submission सर्विस दोनों स्टोर्स के लिए review की तैयारी और रिजेक्शन फ़ीडबैक $599 में कवर करती है; डेवलपर अकाउंट फ़ीस अलग है।

2.1 की समस्याएँ अक्सर बाद के अपडेट में लौट आती हैं: कोई नया feature flag, बदली गई API key या एक्सपायर हुआ डेमो अकाउंट। इस टेस्ट प्लान को App Store submission checklist के साथ अपनी रिलीज़ रूटीन में जोड़ें। अपडेट के लिए, phased release यह सीमित करता है कि छूटा हुआ बग कितने यूज़र्स तक पहुँचे। किसी रिजेक्ट हुए बिल्ड पर दूसरी राय के लिए रिजेक्शन मैसेज के साथ yagyeshsrbobde@gmail.com पर ईमेल करें।