App Store Review Guidelines की व्याख्या

App Store का हर ऐप, और हर अपडेट, Apple के लोग एक दस्तावेज़ के आधार पर जाँचते हैं: App Store Review Guidelines। इसे याद करने की ज़रूरत नहीं है। आपको इसकी बनावट पता होनी चाहिए, और वे कुछ नियम जिन्हें सबमिट करने से पहले ध्यान से जाँचना ज़रूरी है।

संक्षेप में

गाइडलाइंस में पांच सेक्शन हैं: सुरक्षा (Safety), परफ़ॉर्मेंस (Performance), बिज़नेस (Business), डिज़ाइन (Design) और कानूनी (Legal)। सबमिट करने से पहले पांच क्षेत्र ध्यान से जाँचने लायक हैं: completeness (2.1), metadata (2.3), in-app purchase (3.1.1), spam और नकल (4.3), और privacy (5.1.1)। Apple का अपना आँकड़ा सिर्फ़ पहले क्षेत्र का है: औसतन 40% से ज़्यादा अनसुलझी समस्याएँ 2.1 से जुड़ी होती हैं। रिजेक्ट होने पर ठीक करके दोबारा सबमिट करें, या App Store Connect में App Review को जवाब दें। अपील तभी करें जब इससे बात न बने।

Apple ने गाइडलाइंस को आखिरी बार October 16, 2026 को अपडेट किया। नीचे दिए गए सेक्शन के सारांश आसान भाषा में हमारे शब्दों में हैं, Apple के शब्दों में नहीं। सिर्फ़ उद्धरण चिह्नों के अंदर का टेक्स्ट Apple का है।

गाइडलाइंस कैसे व्यवस्थित हैं

Apple अपने सिद्धांत से शुरू करता है: “हम यूज़र्स को ऐप पाने का सुरक्षित अनुभव और सभी डेवलपर्स को सफल होने का बेहतरीन मौका देना चाहते हैं।” फिर पांच सेक्शन आते हैं, फिर सबमिट करने से पहले और बाद के लिए एक छोटी checklist। आसान भाषा में, पांच सेक्शन ये कवर करते हैं:

1. सुरक्षा

आसान भाषा में, सेक्शन 1 लोगों को नुकसान न पहुँचाने के बारे में है। Apple इसे सीधे कहता है: अगर आप लोगों को चौंकाना और ठेस पहुँचाना चाहते हैं, तो “App Store आपके ऐप के लिए सही जगह नहीं है।”

• 1.1 आपत्तिजनक कंटेंट। मानहानि करने वाला, भेदभाव वाला या दुर्भावना से भरा कंटेंट नहीं, और ऐसा कुछ नहीं जो “घृणा पैदा करने के इरादे से” हो।
• 1.2 यूज़र का बनाया कंटेंट। अगर लोग कंटेंट पोस्ट या जनरेट कर सकते हैं, AI से कंटेंट बनाने सहित, तो आपको फ़िल्टर, रिपोर्ट और ब्लॉक करने के तरीके चाहिए।
• 1.3 बच्चे। Kids श्रेणी के ऐप पर बाहरी लिंक, खरीदारी, third-party विज्ञापन और analytics, और डेटा के लिए अतिरिक्त नियम हैं।
• 1.4 शारीरिक नुकसान। जो मेडिकल ऐप गलत डेटा दे सकते हैं, उनकी ज़्यादा बारीकी से जाँच होती है।
• 1.5 डेवलपर की जानकारी। ऐप और उसके support URL में आपसे संपर्क करने का आसान तरीका होना चाहिए।
• 1.6 डेटा सुरक्षा। यूज़र की जानकारी को सुरक्षित तरीके से संभालें।

2. परफ़ॉर्मेंस

आसान भाषा में, सेक्शन 2 पूछता है कि ऐप काम करता है या नहीं और उसका वर्णन ईमानदारी से किया गया है या नहीं। इसमें 2.1 शामिल है, वह गाइडलाइन जिससे Apple 40% से ज़्यादा अनसुलझी समस्याओं को जोड़ता है।

• 2.1 ऐप का पूरा होना। अंतिम संस्करण सबमिट करें, जो डिवाइस पर टेस्ट किया गया हो, जिसके URLs काम करते हों और जिसमें placeholder टेक्स्ट न हो। अगर ऐप में login है, तो demo खाते की जानकारी दें, “और अपनी back-end सेवा चालू रखें!”
• 2.2 बीटा टेस्टिंग। Demo और बीटा, TestFlight पर होने चाहिए, App Store पर नहीं। हमारी TestFlight गाइड देखें।
• 2.3 सही metadata। विवरण, screenshots, previews और privacy की जानकारी ऐप के मुख्य अनुभव को दिखाने चाहिए।
• 2.4 हार्डवेयर के साथ संगतता। जहाँ तक संभव हो, iPhone ऐप iPad पर भी चलने चाहिए, और बिजली का इस्तेमाल कुशलता से करना चाहिए।
• 2.5 सॉफ़्टवेयर की ज़रूरतें। सिर्फ़ सार्वजनिक APIs इस्तेमाल करें, और मौजूदा OS पर चलें।

3. बिज़नेस

आसान भाषा में, सेक्शन 3 पैसे के बारे में है। अगर आपका बिज़नेस मॉडल साफ़ नहीं है, तो metadata और समीक्षा के नोट्स में उसे समझाएँ; Apple के अनुसार उलझन “आपकी समीक्षा में देरी करेगी और रिजेक्शन की वजह बन सकती है।” Apple यह भी कहता है कि वह ऐसे ऐप और in-app purchase आइटम वितरित नहीं करेगा जो “साफ़ तौर पर लूट” हैं, और ऐसे महंगे ऐप रिजेक्ट करेगा जो बेतुकी ऊँची कीमतों से यूज़र्स को ठगने की कोशिश करते हैं। वह यह भी जोड़ता है कि रिव्यू या रैंकिंग में हेरफेर करने पर आपको Developer Program से निकाला जा सकता है।

• 3.1.1 In-app purchase, डिजिटल सुविधाएँ या कंटेंट अनलॉक करने के लिए।
• 3.1.2 Subscriptions को लगातार मूल्य देना चाहिए।
• 3.1.3 खरीदारी के दूसरे तरीके, खास मामलों के लिए, जैसे reader ऐप और व्यक्ति से व्यक्ति वाली सेवाएँ।
• 3.2 दूसरे स्वीकार्य और अस्वीकार्य बिज़नेस मॉडल बताता है।

4. डिज़ाइन

आसान भाषा में, सेक्शन 4 ऐसे ऐप के लिए न्यूनतम मानक तय करता है जो रखने लायक हो। Apple इन्हें “मंज़ूरी के लिए न्यूनतम मानक” कहता है।

• 4.1 नकल। “अपने खुद के आइडिया लाएँ।” किसी दूसरे ऐप का नाम या UI कॉपी न करें।
• 4.2 न्यूनतम कार्यक्षमता। ऐप में “ऐसी सुविधाएँ, कंटेंट और UI होने चाहिए जो उसे दोबारा पैक की गई वेबसाइट से आगे ले जाएँ।” पतले wrapper में वेब ऐप के इस नियम पर खरा न उतरने का जोखिम है; Apple सुविधाओं, कंटेंट और UI को परखता है, तकनीक को नहीं। हमारा लेख iOS ऐप के लिए Lovable के विकल्प देखें।
• 4.3 Spam। एक जैसे ऐप नहीं, और भरी हुई श्रेणियों में कुछ नया दिए बिना उनके रूप नहीं।
• 4.8 Login सेवाएँ। अगर मुख्य खाते के लिए आप Google Sign-In जैसा third-party login इस्तेमाल करते हैं, तो उसके बराबर एक और विकल्प भी दें, जो डेटा को नाम और ईमेल तक सीमित रखे और लोगों को अपना ईमेल निजी रखने दे।
• 4.10 आप push notifications या कैमरा जैसी built-in क्षमताओं के लिए पैसे नहीं ले सकते।

5. कानूनी

आसान भाषा में, सेक्शन 5 कानून के बारे में है। यह इस तरह शुरू होता है: ऐप को “हर उस जगह की सभी कानूनी ज़रूरतों का पालन करना चाहिए जहाँ आप उन्हें उपलब्ध कराते हैं।”

• 5.1 Privacy। Privacy policy, अनुमतियाँ, कम से कम डेटा, खाता डिलीट करना, और third parties के साथ शेयर करना।
• 5.2 बौद्धिक संपदा। सिर्फ़ वही कंटेंट इस्तेमाल करें जो आपने बनाया है या जिसका लाइसेंस आपके पास है।
• 5.3 Gaming, जुआ और लॉटरी। इन पर कड़े नियम हैं; समीक्षा में ज़्यादा समय लगने की उम्मीद रखें।
• 5.4 और 5.5, VPN ऐप और mobile device management को कवर करते हैं।
• 5.6 डेवलपर की आचार संहिता। सम्मान से पेश आएँ, App Review को दिए जवाबों में भी।

सबमिशन से पहले जाँचने वाले पांच क्षेत्र

ये पांच क्षेत्र हमारा संपादकीय चुनाव हैं: ऐसे नियम जो आसानी से छूट जाते हैं और जिन्हें Apple ने अच्छी तरह दस्तावेज़ किया है। Apple सिर्फ़ पहले क्षेत्र का आँकड़ा प्रकाशित करता है।

2.1 ऐप का पूरा होना

Apple के App Review पेज के अनुसार, औसतन 40% से ज़्यादा अनसुलझी समस्याएँ गाइडलाइन 2.1 से जुड़ी होती हैं। इसमें crash, placeholder कंटेंट, टूटे लिंक और समीक्षा की अधूरी जानकारी आती है।

• रिलीज़ बिल्ड को नए iOS वाले असली डिवाइस पर टेस्ट करें।
• हर “Lorem ipsum”, टेस्ट इमेज और खाली स्क्रीन को बदलें।
• जाँचें कि support लिंक और privacy policy लिंक काम करते हैं।
• App Review Information में काम करने वाला demo खाता और समीक्षक के लिए ज़रूरी हर चरण जोड़ें।
• समीक्षा के दौरान अपना backend चालू रखें।

2.3 सही metadata

आपके स्टोर पेज को उसी ऐप का वर्णन करना चाहिए जो आप असल में जारी करते हैं।

• 2.3.1 नई सुविधाओं का वर्णन समीक्षा के नोट्स में “विशिष्ट रूप से” करना चाहिए; सामान्य वर्णन रिजेक्ट होते हैं।
• 2.3.3 Screenshots में ऐप इस्तेमाल होता दिखना चाहिए, “सिर्फ़ title art, login पेज या splash स्क्रीन नहीं।”
• 2.3.7 ऐप के नाम 30 अक्षरों तक सीमित हैं। Metadata को ट्रेडमार्क वाले शब्दों, लोकप्रिय ऐप के नामों या कीमतों से न भरें।
• 2.3.8 Icons, screenshots और previews को 4+ age rating के लायक होना चाहिए, भले ही ऐप की rating ज़्यादा हो।

3.1.1 In-app purchase

अगर लोग ऐप के अंदर सुविधाएँ या कंटेंट अनलॉक करने के लिए पैसे देते हैं, जैसे subscriptions, प्रीमियम कंटेंट या पूरा संस्करण, तो आपको in-app purchase इस्तेमाल करना होगा। आप license keys या QR codes जैसे अपने अनलॉक तरीके इस्तेमाल नहीं कर सकते। ऐप के बाहर इस्तेमाल होने वाले भौतिक सामान और सेवाओं के लिए उल्टा नियम है: गाइडलाइन 3.1.3(e) के अनुसार उनके लिए भुगतान के दूसरे तरीके इस्तेमाल होने चाहिए, जैसे Apple Pay या कार्ड।

4.3 Spam

दो चीज़ें इसे ट्रिगर करती हैं। पहली, एक ही ऐप के लिए कई Bundle IDs, जैसे हर शहर के लिए अलग ऐप; Apple इसके बजाय एक ऐप का सुझाव देता है, जिसमें अलग-अलग रूपों के लिए in-app purchase हो। दूसरी, ऐसे ऐप जो “पहले से बड़े पैमाने पर उपलब्ध ऐप से अलग पहचाने नहीं जा सकते।” Apple डेटिंग, फ़्लैशलाइट, साउंड इफ़ेक्ट, वॉलपेपर, साधारण टाइमर और भविष्य बताने वाले ऐप को अच्छी तरह स्थापित श्रेणियाँ बताता है, और नए ऐप तब तक स्वीकार नहीं करता “जब तक वे सार्थक रूप से अलग या बेहतर अनुभव न दें।” अगर आप किसी भरी हुई श्रेणी में आ रहे हैं, तो समीक्षा के नोट्स में बताएँ कि आपके ऐप में क्या अलग है।

5.1.1 डेटा इकट्ठा करना और स्टोर करना

यह privacy का वह नियम है जिसके सबसे ज़्यादा हिस्से हैं:

• (i) Privacy policy। इसका लिंक App Store Connect में और ऐप के अंदर दें। इसमें बताना होगा कि आप क्या इकट्ठा करते हैं, कैसे, क्यों, किसके साथ शेयर करते हैं, और लोग अपना डेटा कैसे डिलीट कर सकते हैं।
• (ii) अनुमति। यूज़र या इस्तेमाल का डेटा इकट्ठा करने से पहले सहमति लें, लोगों को उसे वापस लेने का आसान तरीका दें, और ऐसे purpose strings लिखें जो साफ़ बताएँ कि आपको डेटा क्यों चाहिए।
• (v) खाते से sign-in। अगर ऐप में खाते पर आधारित कोई खास सुविधा नहीं है, तो लोगों को login किए बिना इसे इस्तेमाल करने दें। अगर लोग खाता बना सकते हैं, तो उन्हें ऐप के अंदर उसे डिलीट करने की सुविधा मिलनी चाहिए।

गाइडलाइन 5.1.2(i) एक और बात जोड़ती है, जिसकी कई AI ऐप को ज़रूरत होती है: आपको “साफ़ तौर पर बताना होगा कि निजी डेटा कहाँ third parties के साथ शेयर होगा, third-party AI सहित,” और पहले साफ़ अनुमति लेनी होगी। App Store Connect में App Privacy के जवाब इन सब बातों से मेल खाने चाहिए; हमारी App Store Connect गाइड दिखाती है कि वे कहाँ भरे जाते हैं।

जब समीक्षा आपके पक्ष में न जाए

अगर कोई सबमिशन पास नहीं होता, तो आपको App Store Connect में अपने ऐप के App Review सेक्शन में मैसेज मिलता है। कई डेवलपर अब भी इसे Resolution Center कहते हैं। इसमें गाइडलाइन का नाम और समस्या का वर्णन होता है।

1. बताई गई गाइडलाइन पढ़ें

   मैसेज में दिया गया गाइडलाइन नंबर खोलें और सिर्फ़ सारांश नहीं, पूरा टेक्स्ट पढ़ें।

2. अगर समस्या असली है, तो ठीक करें और दोबारा सबमिट करें

   अगर कोड बदला है, तो नया बिल्ड अपलोड करें, नहीं तो metadata अपडेट करें। समीक्षा के नोट्स में बताएँ कि आपने क्या बदला।

3. अगर कुछ साफ़ नहीं है, तो App Review को जवाब दें

   App Store Connect में Reply to App Review पर क्लिक करें। Apple के अनुसार आपके ऐप से परिचित एक विशेषज्ञ जवाब देगा। ठोस बात करें: सटीक सुविधा, गाइडलाइन या चरण। आप कॉल भी माँग सकते हैं; Apple के अनुसार कॉल आम तौर पर तीन से पांच कामकाजी दिनों में हो जाती हैं।

4. अगर आप अब भी असहमत हैं, तो अपील करें

   App Review Board में अपील दर्ज करें। Apple कहता है कि पहले रिजेक्शन का जवाब दें, हर रिजेक्ट हुए ऐप के लिए सिर्फ़ एक अपील करें, और उसी एक अपील में बताई गई हर गाइडलाइन का बिंदुवार जवाब दें।

दो और विकल्प जानने लायक हैं। अगर आप bug fix वाला अपडेट सबमिट करते हैं और समीक्षक को दूसरी समस्याएँ मिलती हैं, तो Apple मौजूदा सबमिशन को मंज़ूरी देकर बाकी समस्याएँ अगली बार ठीक करने का विकल्प दे सकता है, बशर्ते कोई कानूनी या सुरक्षा से जुड़ी चिंता न हो। और सबमिट करने से पहले आप गाइडलाइंस के बारे में पूछने के लिए App Review के साथ 30 मिनट का वीडियो अपॉइंटमेंट बुक कर सकते हैं।

जल्दी समीक्षा

Apple के अनुसार App Review आम तौर पर कम से कम 50% सबमिशन की समीक्षा 24 घंटे से कम में और 90% की 48 घंटे से कम में करता है। अगर आप इंतज़ार नहीं कर सकते, तो दो मामलों में जल्दी समीक्षा का अनुरोध कर सकते हैं:

• गंभीर bug fix। सबमिट करते समय Notes फ़ील्ड में मौजूदा संस्करण पर bug दोहराने के चरण लिखें।
• किसी इवेंट से जुड़ी रिलीज़। इवेंट, उसकी तारीख और आपका ऐप उससे कैसे जुड़ा है, यह बताएँ। Apple इसके बजाय रिलीज़ को पहले से शेड्यूल करने की सलाह देता है।

सिर्फ़ पहले से सबमिट किए गए ऐप की जल्दी समीक्षा हो सकती है, और Apple कहता है कि अनुरोध “सिर्फ़ असली ज़रूरी मामलों के लिए रखें।” Request an Expedited App Review फ़ॉर्म इस्तेमाल करें।

सबमिट करने से पहले

Apple की अपनी checklist चार बातों में सिमट जाती है: crash और bugs के लिए टेस्ट करें, metadata को पूरा और सही रखें, अपनी संपर्क जानकारी मौजूदा रखें, और App Review को पूरी पहुँच दें, अगर ऐप में sign-in चाहिए तो demo खाते के साथ। फिर Add for Review चुनें और draft सबमिशन में Submit for Review चुनें। AI से ऐप बनाने की हमारी गाइड इसे उसी क्रम में रखती है जिसमें आप इससे गुज़रेंगे।

AirBuild यह चक्र आपके लिए संभालता है। Basic, Plus और Ultra पर यह App Store लिस्टिंग, screenshots और समीक्षा के नोट्स तैयार करता है, आपका ऐप सबमिट करता है, समीक्षा को ट्रैक करता है, App Review के फ़ीडबैक का जवाब देता है, समस्याएँ ठीक करता है और दोबारा सबमिट करता है।

अक्सर पूछे जाने वाले सवाल

App Store Review Guidelines क्या हैं?

ये App Store पर ऐप के लिए Apple के नियम हैं, जो पांच सेक्शन में हैं: सुरक्षा (Safety), परफ़ॉर्मेंस (Performance), बिज़नेस (Business), डिज़ाइन (Design) और कानूनी (Legal)। अपडेट समेत हर सबमिशन की समीक्षा इन्हीं के आधार पर होती है।

ऐप रिजेक्ट होने की सबसे आम वजह क्या है?

Apple रिजेक्शन की वजहों की पूरी रैंकिंग प्रकाशित नहीं करता। उसके App Review पेज के अनुसार, औसतन 40% से ज़्यादा अनसुलझी समस्याएँ गाइडलाइन 2.1, App Completeness से जुड़ी होती हैं। इसमें crash, placeholder कंटेंट, टूटे लिंक और समीक्षा की अधूरी जानकारी, जैसे demo खाता, शामिल हैं।

App Store रिजेक्शन का जवाब कैसे दूँ?

App Store Connect में ऐप के App Review सेक्शन में मैसेज पढ़ें। अगर समस्या असली है, तो उसे ठीक करें और दोबारा सबमिट करें। अगर आपका कोई सवाल है या आपको लगता है कि समीक्षक ने ऐप को गलत समझा, तो वहीं ठोस जानकारी के साथ App Review को जवाब दें। App Review Board में अपील उसके बाद ही करें।

App Review में कितना समय लगता है?

Apple के अनुसार App Review आम तौर पर कम से कम 50% सबमिशन की समीक्षा 24 घंटे से कम में और 90% की 48 घंटे से कम में करता है। जटिल ऐप या एक ही समस्या पर बार-बार रिजेक्शन में ज़्यादा समय लग सकता है।

क्या मैं App Review को तेज़ कर सकता हूँ?

ऐप सबमिट होने के बाद, आप गंभीर bug fix या किसी इवेंट से जुड़ी रिलीज़ के लिए जल्दी समीक्षा का अनुरोध कर सकते हैं। Apple कहता है कि ऐसे अनुरोध सिर्फ़ असली ज़रूरत के लिए रखें।