नोट, अगस्त 2026: यह पोस्ट एक पुरानी रिलीज़ की है और उस समय के टियर ढांचे के बारे में बताती है। AlcoLog ने v1.2.0 में Pro टियर को Premium में मिला दिया, इसलिए अब सिर्फ़ एक पेड टियर है। इस बदलाव में कुछ भी नहीं छूटा, और जिनके पास Pro था, वे बिना किसी अतिरिक्त खर्च के Premium पर आ गए।
अगर आप सब्सक्रिप्शन, In-App Purchase, Watch कंपैनियन ऐप, विजेट, या सेहत से जुड़ी किसी भी तरह की पोज़िशनिंग वाला v1.0 iOS ऐप शिप करने वाले हैं, तो App Review की प्रक्रिया डॉक्यूमेंटेशन से जितनी लगती है, उससे ज़्यादा मुश्किल होगी। यह पोस्ट एक लॉन्च चक्र का ब्योरा है (पांच दिन में चार रिजेक्शन, पांच रिव्यूअर, एक ही बाइनरी), और उन पैटर्न का भी जिनकी वजह से यह चक्र झेला जा सका। मैं इसे इसलिए शेयर कर रहा हूं क्योंकि गंभीर इंडी ऐप शिप करने का यह हिस्सा सबसे कम लिखा गया है, और जो लिखा गया है (WWDC सेशन, Review Guidelines पेज, डेवलपर फ़ोरम), वह रोज़ की असलियत से मेल नहीं खाता।
अगर आप चक्र के बीच में हैं और ठोस सुधार ढूंढ रहे हैं, तो सीधे “सबमिट करने से पहले क्या ठीक करें” और “समझने लायक पैटर्न” पर जाएं। अगर आपको संदर्भ चाहिए, तो निजी टाइमलाइन दूसरे हिस्से में है।
# सबमिट करने से पहले क्या ठीक करें
ये वे चीज़ें हैं जो चार रिजेक्शन में सामने आईं। अगर आप इन्हें पहले ही ठीक कर लें, तो सब्सक्रिप्शन वाले संवेदनशील कैटेगरी के v1.0 के लिए रिजेक्शन की ज़्यादातर गुंजाइश खत्म हो जाती है।
# सब्सक्रिप्शन पेवॉल पर कीमत दिखाने का क्रम
सब्सक्रिप्शन के लिए Apple की Human Interface Guidelines कीमत दिखाने के तरीके पर बिल्कुल साफ़ हैं। जो रकम बिल की जाएगी, वह कीमत का सबसे प्रमुख हिस्सा होनी चाहिए। मार्केटिंग की सहज सोच (छूट को जीत जैसा दिखाओ) यहां गलत है। नियमों की सहज सोच (बिल की जाने वाली रकम को टाइपोग्राफ़ी में सबसे आगे रखो) सही है।
व्यवहार में इसका मतलब: नियमित कीमत सबसे बड़ी और सबसे मोटी होनी चाहिए। शुरुआती या छूट वाली कीमत छोटी होनी चाहिए, साफ़ “First period:” लेबल के साथ। छोटे मार्करों में प्रतिशत वाले बैज से बचें (“25% OFF” की जगह “LAUNCH OFFER” इस्तेमाल करें)। इस बात पर 3.1.2© Payments and Subscriptions का पालन हर रिव्यूअर ने एक जैसा करवाया।
# डेटा डिलीट करने का साफ़ रास्ता
भले ही आपका “अकाउंट” सिर्फ़ एक ऑप्ट-इन गुमनाम आइडेंटिफ़ायर हो, Apple का 5.1.1(v) एक लेबल वाला, दिखने वाला और तुरंत काम करने वाला डिलीट करने का रास्ता मांगता है। टॉगल बंद करने को ही डिलीट मान लेना डेवलपर की तरफ़ से नियमों के मुताबिक लगता है, लेकिन मौजूदा पालन में यह काफ़ी नहीं है।
पहले बिल्ड से ही प्राइवेसी या सेटिंग्स स्क्रीन पर एक साफ़ “Delete My Data” बटन रखें। एक पुष्टि वाला अलर्ट जोड़ें। पक्का करें कि आसपास का टेक्स्ट असल में डिलीट होने के तरीके को बताए, न कि कोई ऐसी अस्थायी समय-सीमा जिसे आप बाद में बदलने का इरादा रखते हों।
# Info.plist में बची-खुची घोषणाओं की जांच करें
बैकग्राउंड मोड, बैकग्राउंड फ़ेच, लोकेशन एंटाइटलमेंट, HealthKit घोषणाएं और ऐसी ही Info.plist एंट्री महीनों तक बिना इस्तेमाल के पड़ी रह सकती हैं, जबकि कोडबेस बदलता रहता है। जब वे किसी असली फ़ीचर से मेल नहीं खातीं, तो उन पर सवाल उठता है। यहां 2.5.4 Software Requirements का पालन मशीनी और बिल्कुल साफ़ है।
खास तौर पर: हर UIBackgroundModes एंट्री किसी ऐसे फ़ीचर से जुड़ी होनी चाहिए जो सच में उसका इस्तेमाल करता हो। अगर आपका ऐप “location” को बैकग्राउंड मोड के रूप में घोषित करता है, लेकिन आप कभी लगातार बैकग्राउंड लोकेशन इस्तेमाल नहीं करते और allowsBackgroundLocationUpdates = false है, तो घोषणा हटा दें। रीजन मॉनिटरिंग को इसकी ज़रूरत नहीं होती। यह जांच दस मिनट लेती है और एक रिजेक्शन चक्र बचा देती है।
# App Store मेटाडेटा में काम करता हुआ Terms of Use लिंक
App Store Connect में Privacy Policy फ़ील्ड के बारे में सब जानते हैं। Terms of Use की ज़रूरत के बारे में कम लोग जानते हैं। अगर आप Apple का स्टैंडर्ड EULA इस्तेमाल कर रहे हैं, तो App Description में Terms of Use का लिंक शामिल करें। अगर आप कस्टम EULA इस्तेमाल कर रहे हैं, तो उसे App Store Connect के कस्टम EULA फ़ील्ड में जोड़ें।
टर्म्स पेज पर खुद सभी पेड प्रोडक्ट, सब्सक्रिप्शन की अवधि, कीमत और रिन्यूअल का तरीका बताया जाना चाहिए। ज़्यादातर टीमों के पास ये चीज़ें अलग-अलग पेजों पर बिखरी होती हैं या प्राइवेसी पॉलिसी में दबी होती हैं। इन्हें एक ऐसे टर्म्स पेज पर इकट्ठा करें जिसे रिव्यूअर दो मिनट में पढ़ सके।
# App Preview वीडियो: सीधी स्क्रीन रिकॉर्डिंग इस्तेमाल करें
3D फ़ोन मॉकअप, डिवाइस फ़्रेम और स्टाइल वाली मार्केटिंग कंपोज़िशन 2.3.4 Accurate Metadata के तहत रिव्यूअर की मर्ज़ी पर निर्भर होते हैं। सार्वजनिक गाइडेंस पेज डिवाइस फ़्रेम को साफ़ तौर पर मना नहीं करता, लेकिन लगता है कि रिव्यूअर जिस अंदरूनी ट्रेनिंग सामग्री से काम करते हैं, वह मना करती है। सादी, नेटिव रेज़ोल्यूशन वाली स्क्रीन रिकॉर्डिंग बिना किसी शक के सुरक्षित हैं।
मार्केटिंग की सजावट अपनी वेबसाइट, सोशल मीडिया और Reddit के लिए बचाकर रखें। App Preview की जगह पर स्क्रीन रिकॉर्डिंग लगाएं। “चमकदार मॉकअप प्रीव्यू” और “सीधी स्क्रीन रिकॉर्डिंग प्रीव्यू” के बीच कन्वर्ज़न का अंतर छोटा है। जोखिम में कमी बड़ी है।
# App Review Notes में IAP तक पहुंचने का साफ़ रास्ता
रिव्यूअर हर ऐप पर 5 से 15 मिनट के समय-बजट में काम करते हैं। वे हमेशा वर्ज़न से जुड़ा हर IAP नहीं ढूंढ पाएंगे। अगर आपके IAP ऐप में अलग-अलग रास्तों से मिलते हैं (अलग पेवॉल, अलग कार्ड, गहरा नेविगेशन), तो अपने App Review Notes में हर IAP के लिए एक-एक क्लिक का नेविगेशन रास्ता लिखें।
काम करने वाला फ़ॉर्मेट (रिव्यूअर के लिए अंग्रेज़ी में ही लिखें):
Premium subscriptions and Lifetime IAP: Settings tab > Premium card > Get Premium button > Premium upgrade sheet Pro subscriptions and Lifetime IAP: Settings tab > Pro card > Get Pro button Consumable Tip Jar items: Settings tab > scroll past tier cards > Tip Jar card > Show Tip Options
यह ज़रूरत से ज़्यादा लगता है। लेकिन यह एक खास रिजेक्शन चक्र (Guideline 2.1(b) Information Needed) रोकता है, जो वरना आपका एक दिन खा जाता है।
# सबमिशन और तय लॉन्च तारीख के बीच कैलेंडर में गुंजाइश
संवेदनशील कैटेगरी में सब्सक्रिप्शन वाले v1.0 सबमिशन के लिए, पहले सबमिशन और बाहर घोषित की गई लॉन्च तारीख के बीच कम से कम सात कैलेंडर दिन रखें। अगर आप तुरंत जवाब दें, तो हर रिजेक्शन चक्र लगभग 24 घंटे चलता है। संवेदनशील कैटेगरी के v1.0 सबमिशन के लिए चार रिजेक्शन चक्र एक असली, सबसे खराब स्थिति है।
अगर आपकी लॉन्च तारीख बाहर तय हो चुकी है (Pre-Order सेट है, In-App Events शेड्यूल हैं, मार्केटिंग बुक है, पत्रकारों से बात हो चुकी है), तो सात दिन की गुंजाइश न्यूनतम है। दस दिन ज़्यादा आरामदायक है। सात से कम, और एक ही प्रक्रिया वाले रिजेक्शन की वजह से तारीख छूटने का खतरा है।
# समझने लायक पैटर्न
चक्र के अंदर से कुछ बातें जो डॉक्यूमेंटेशन से साफ़ नहीं होतीं।
# हर रिजेक्शन अलग चीज़ें ढूंढता है
चार रिजेक्शन आए, और हर एक में अलग-अलग चीज़ें बताई गईं, कोई दोहराव नहीं। हर रिव्यूअर के पास वह हर स्क्रीन थी जिसे पिछले रिव्यूअर ने पास किया था। पहले रिव्यूअर ने मेटाडेटा में EULA लिंक पर सवाल उठाया। दूसरे ने उसी बाइनरी में तीन अलग चीज़ें बताईं (बैकग्राउंड मोड, कीमत का प्रदर्शन, डिलीट बटन)। तीसरे ने एक मार्केटिंग एसेट पर सवाल उठाया। चौथे ने नेविगेशन का सवाल पूछा।
यह कोई बग नहीं है। App Review के ढांचे की यह एक खासियत है। लगता है कि रिव्यू ऐप के हिसाब से नहीं, बल्कि मुद्दे के हिसाब से होते हैं। रिव्यूअर अपने समय-बजट में पकड़ी गई पहली बड़ी समस्या पर रुक जाते हैं। उनसे पूरी जांच की उम्मीद नहीं की जाती, और सिस्टम उन हिस्सों को “पहले पास हुआ” का दर्जा नहीं देता जिन्हें पिछले रिव्यूअर ने मंज़ूर किया था। यह ढांचा डेवलपर के अनुभव के बजाय संस्था की रफ़्तार को तरजीह देता है।
इसका मतलब: किसी एक रिव्यू से आपको पूरी जांच नहीं मिल सकती। आपको सिर्फ़ वह मिलता है जो मौजूदा रिव्यूअर अपने समय में ढूंढ पाता है, और आपको यह मानना पड़ता है कि अगला रिव्यूअर अगली बार अपने आप कुछ और भी ढूंढ सकता है।
# हर रिजेक्शन का दायरा अक्सर पिछले से छोटा होता है
यह एक ढीला पैटर्न है, गारंटी नहीं। पहला रिजेक्शन अक्सर ठोस होता है (कोई छूटी हुई ज़रूरत, ढांचे की कोई समस्या)। दूसरा भी ठोस होता है, लेकिन ज़्यादा चेकलिस्ट जैसा। तीसरा किनारे के मेटाडेटा की तरफ़ चला जाता है। चौथा कभी-कभी रिजेक्शन के बजाय बस प्रक्रिया का एक सवाल होता है।
वजह यह नहीं कि ऐप हर बार “बेहतर हो रहा है”। वजह यह है कि बाइनरी और मेटाडेटा में रिव्यू करने लायक हिस्सा हर बार घटता जाता है, क्योंकि पहले बताई गई चीज़ें ठीक हो जाती हैं और पहले पास हुई चीज़ें दायरे से बाहर हो जाती हैं। रिव्यूअर अलग-अलग तौर पर उपलब्ध चेकलिस्ट को खत्म करते जाते हैं, इसलिए बाद के रिव्यू के पास ढूंढने को कम बचता है।
चक्र के दौरान यह पैटर्न तसल्ली देता है, लेकिन इस पर भरोसा न करें। चक्र के आखिर का कोई रिव्यूअर अब भी कोई ऐसी ठोस चीज़ ढूंढ सकता है जो पहले वालों से छूट गई हो।
# रिव्यूअर की गहराई में बहुत फ़र्क होता है
एक ही बाइनरी के चार रिव्यू में, हर रिव्यूअर ने जो पाया उसमें बड़ा फ़र्क था। एक ने तीन चीज़ें पाईं। दूसरे ने किनारे की एक चीज़। तीसरे ने ऐसा सवाल पूछा जिसका जवाब ऐप के दूसरे टैब में एक कार्ड पर टैप करके मिल जाता।
किसी भी बार आपका सबमिशन किस रिव्यूअर के पास जाएगा, इस पर आपका कोई ज़ोर नहीं है। इस फ़र्क के लिए योजना बनाएं। यह न मानें कि अगली बार का रिव्यू पिछले से ज़्यादा गहरा या ज़्यादा नरम होगा। ये एक चौड़े दायरे से लिए गए स्वतंत्र नमूने हैं।
# Beta App Review की मंज़ूरी पूरे App Review की मंज़ूरी का संकेत नहीं है
दोनों पाइपलाइन की टीमें अलग हैं और मानदंड अलग हैं। अगर कोई बिल्ड Beta में उन्हीं फ़ीचर के साथ पास हो जाए जिन पर प्रोडक्शन रिव्यू में सवाल उठता है, तो यह विरोधाभास नहीं है। ये दो अलग रिव्यू प्रक्रियाएं हैं।
अगर आप प्रोडक्शन के लिए तैयारी पक्की करने के लिए TestFlight का इस्तेमाल कर रहे हैं, तो आप उससे गलत संकेत ले रहे हैं। TestFlight बिल्ड के सही होने और बुनियादी नियमों से जुड़ी समस्याएं पकड़ता है। प्रोडक्शन App Review पूरे नियमों की जांच करता है। दोनों एक-दूसरे की जगह नहीं ले सकते।
# संवेदनशील कैटेगरी की जांच के कारण जुड़ते जाते हैं
सब्सक्रिप्शन, खास तौर पर शुरुआती कीमत या ट्रायल ऑफ़र के साथ, अपने आप 3.1.2 की जांच शुरू कर देते हैं। सेहत से जुड़ी कैटेगरी (शराब, फ़िटनेस, मानसिक स्वास्थ्य, नींद) रिव्यूअर का ध्यान 1.4.1 के मेडिकल दावों वाली चिंताओं की ओर खींचती हैं। प्राइवेसी से जुड़े फ़ीचर (लोकेशन, HealthKit, गुमनाम आइडेंटिफ़ायर) 5.1.1 की कड़ी जांच लाते हैं। पहले वर्ज़न वाले v1.0 सबमिशन का पूरा रिव्यू होता है। लॉन्च तारीख से जुड़े In-App Events मेटाडेटा की कड़ी जांच लाते हैं।
हर कारण अकेले में संभाला जा सकता है। लेकिन ये कई गुना होकर जुड़ते हैं। सब्सक्रिप्शन, कई प्लेटफ़ॉर्म और एक In-App Event वाले संवेदनशील कैटेगरी के गंभीर लॉन्च में हर कारण एक साथ सक्रिय होता है। बिना IAP वाला एक फ़्री, एक स्क्रीन वाला यूटिलिटी ऐप 2 मिनट में पास हो जाता है। आपके रिव्यू का अनुभव कितना मुश्किल होगा, इसका संबंध आपके लॉन्च की गंभीरता और फैलाव से है, आपके ऐप की क्वालिटी से नहीं।
# डॉक्यूमेंटेशन और पालन हमेशा पूरी तरह मेल नहीं खाते
कोई रिजेक्शन ऐसी गाइडेंस का हवाला दे सकता है जो जुड़े हुए सार्वजनिक पेज पर साफ़ तौर पर नहीं दिखती। रिव्यूअर अंदरूनी ट्रेनिंग सामग्री से काम करते हैं, जो सार्वजनिक Review Guidelines से मिलती-जुलती है लेकिन उनके जैसी बिल्कुल नहीं है। अगर कोई रिजेक्शन सार्वजनिक डॉक्यूमेंटेशन से मेल नहीं खाता, तो आप विनम्रता से आपत्ति कर सकते हैं। कभी फ़ैसला पलट जाता है, कभी नहीं।
आपत्ति करें तो Resolution Center में लिखकर करें, एक सधे हुए पैराग्राफ़ में जो सार्वजनिक गाइडेंस को उद्धृत करे और पूछे कि कौन सी खास धारा लागू की जा रही है। भाषा में झुंझलाहट न आने दें। रिव्यूअर समय-बजट में जवाब पढ़ रहा है, और जिस जवाब को ध्यान से पढ़ा जाता है, वह वही है जो इस बात का सम्मान करता है।
# रिजेक्शन का रचनात्मक जवाब कैसे दें
Resolution Center की बातचीत पर कुछ व्यावहारिक बातें।
# हो सके तो उसी दिन जवाब दें
चक्र से निकलने का सबसे तेज़ रास्ता है चक्र को चलते रहने देना। जब आप जवाब देते हैं, तो हर रिजेक्शन चक्र की घड़ी फिर से शुरू होती है। उसी दिन के जवाब से उसी हफ़्ते में हल निकलता है, और कई दिन के जवाब से चक्र उसी अनुपात में लंबा हो जाता है।
इसके लिए ज़रूरी है कि आपकी टीम जल्दी सुधार शिप करने के हिसाब से बनी हो। एक इंडी डेवलपर के लिए इसका मतलब अक्सर सबमिशन के बाद के दिनों के लिए अपना कैलेंडर खाली करना होता है। सबमिशन के समय को बैकग्राउंड का काम नहीं माना जा सकता।
# अपने सारे सुधार एक ही री-सबमिशन में भेजें
अगर किसी रिजेक्शन में तीन चीज़ें बताई गई हैं, तो दोबारा सबमिट करने से पहले तीनों ठीक करें। “तीन में से दो ठीक कर दीं, तीसरी पर काम चल रहा है” जैसा जवाब न भेजें। अगला रिव्यूअर पूरी तरह अलग चीज़ें ढूंढेगा, और आधे सुधार वाला जवाब बस कतार में एक और चक्र जोड़ देता है।
# सुधार की पुष्टि वाली स्क्रीन रिकॉर्डिंग शामिल करें
किसी भी गैर-मामूली सुधार के लिए, सुधार को काम करते हुए दिखाने वाली 30 सेकंड की स्क्रीन रिकॉर्डिंग जोड़ें। डिलीट करने का फ़्लो, ठीक की गई कीमत का प्रदर्शन, नया नेविगेशन रास्ता। अगर रिव्यूअर खुद वहां तक पहुंचे बिना सुधार देख सके, तो अगली बार उसके मुद्दे को पास करने की संभावना ज़्यादा होती है।
# अपने जवाब में पूरे रिव्यू की मांग करें
यह विनम्र अनुरोध करना ठीक है कि बाकी सभी चिंताएं और चक्रों में बांटने के बजाय मौजूदा रिव्यू में एक साथ उठाई जाएं। यह हमेशा काम नहीं करता, लेकिन कभी-कभी करता है। शब्द मायने रखते हैं (रिव्यूअर के लिए अंग्रेज़ी में): “We have addressed every issue raised so far promptly and in good faith. We would appreciate a comprehensive review against all applicable guidelines in this pass to minimize further cycles.” (यानी: अब तक उठाए गए हर मुद्दे को हमने तुरंत और नेकनीयती से हल किया है। हम आभारी होंगे अगर आगे के चक्रों को कम करने के लिए इसी बार सभी लागू गाइडलाइन के हिसाब से पूरा रिव्यू किया जाए।)
इससे रिव्यूअर ऐसी स्थिति में आ जाता है जहां उसका अगला जवाब या तो ऐप को पास करता है या बाकी हर चिंता सामने रख देता है। दोनों नतीजे एक और एक-मुद्दे वाले रिजेक्शन से बेहतर हैं।
# हर रिव्यू को स्वतंत्र मानें
यह मान लेने का मन करता है कि अगले रिव्यूअर ने पिछले रिव्यूअर के नोट्स पढ़े हैं। शायद नहीं पढ़े। Resolution Center का हर जवाब अपने आप में पूरा होना चाहिए, जो उस व्यक्ति के लिए सबमिशन की स्थिति का सार बताए जिसने पिछली बातचीत नहीं देखी।
इसका मतलब है कि चक्रों के बीच थोड़ा दोहराव ज़रूरी है। जो विस्तृत App Review Notes पहले रिव्यूअर के लिए काम आए, उन्हें तीसरे रिव्यूअर के लिए फिर से जोड़ें या दोहराएं। संस्था की याददाश्त पर भरोसा न करें।
# निजी टाइमलाइन
संदर्भ के लिए, असल में वे पांच दिन ऐसे बीते।
मैंने शनिवार दोपहर बिल्ड 22 सबमिट किया। सबमिशन में 4 ऑटो-रिन्यू होने वाले सब्सक्रिप्शन, 2 नॉन-कंज़्यूमेबल लाइफ़टाइम IAP, 5 कंज़्यूमेबल Tip Jar आइटम, App Description, स्क्रीनशॉट, App Preview वीडियो, लॉन्च वाले हफ़्ते से जुड़ा एक In-App Event, और 175 देशों में लॉन्च तारीख के लिए सेट Pre-Order शामिल थे।
मैंने पिछले छह हफ़्ते हर उस समस्या को एक-एक करके खत्म करने में लगाए थे जिसका मैं अंदाज़ा लगा सकता था। App Review Notes में ऐप के उन हिस्सों के लिए रिव्यूअर के हिसाब से समझाने वाली बातें लिखी गई थीं जिन पर सबसे ज़्यादा सवाल उठने की संभावना थी। DSA ट्रेडर जानकारी एक हफ़्ते पहले मंज़ूर हो चुकी थी। App Privacy न्यूट्रिशन लेबल लाइव थे। Beta App Review कई बिल्ड पास कर चुका था। मुझे लगा कि मैं तैयार हूं।
दिन 2, सुबह 5:15 बजे: पहला रिजेक्शन। Guideline 3.1.2©। App Store मेटाडेटा में काम करने वाला Terms of Use लिंक नहीं था। उसी दिन सुधार शिप किया (ऐप के अंदर अपग्रेड शीट में Terms लिंक जोड़ा, सभी पेड प्रोडक्ट बताने के लिए टर्म्स पेज बढ़ाया, App Description अपडेट किया)। एक दिन का चक्र।
दिन 4, शाम 4:03 बजे: दूसरा रिजेक्शन। एक ही मैसेज में तीन चीज़ें। Guideline 2.5.4 (UIBackgroundModes में बची हुई “location” एंट्री, जो वहां नहीं होनी चाहिए थी)। Guideline 3.1.2© (शुरुआती कीमत बिल की जाने वाली रकम से ज़्यादा प्रमुखता से दिख रही थी)। Guideline 5.1.1(v) (गुमनाम आइडेंटिफ़ायर के टॉगल बंद करने के साथ एक साफ़ लेबल वाला डिलीट बटन चाहिए था)। उसी दिन सुधार शिप किया (Info.plist एंट्री हटाई, कीमत का क्रम उलटा किया, पुष्टि वाले अलर्ट के साथ एक साफ़ “Delete Anonymous Data” बटन जोड़ा)। एक दिन का चक्र।
दिन 5, शाम 5:05 बजे: तीसरा रिजेक्शन। Guideline 2.3.4 Accurate Metadata। App Preview वीडियो में ऐप की स्क्रीन दिखाते 3D फ़ोन मॉकअप थे। रिव्यूअर के नोट में ऐसी सामग्री का ज़िक्र था जो “ऐप को इस्तेमाल होते हुए पर्याप्त रूप से नहीं दिखाती”, और खास तौर पर डिवाइस फ़्रेम का नाम लिया गया था।
मुश्किल यह थी: developer.apple.com/app-store/app-previews/ पर सार्वजनिक गाइडेंस पेज डिवाइस फ़्रेम को साफ़ तौर पर मना नहीं करता। सबसे करीबी लिखा हुआ नियम “Stay within the app” है, जिसके उदाहरण कंधे के ऊपर से लिए गए शॉट और डिवाइस के साथ शारीरिक इंटरैक्शन के बारे में हैं। इनमें से कोई लागू नहीं होता था।
लॉन्च चार दिन दूर था और चार दिन की कुल देरी पहले ही हो चुकी थी, तो मैंने समझौता किया। री-सबमिशन का रास्ता खोलने के लिए App Preview वीडियो हटा दिए। विनम्रता से दोबारा विचार करने को कहा, अगर कोई खास गाइडलाइन धारा मुझसे छूट गई हो। एक विनम्र, सधा हुआ पैराग्राफ़ भेजा जिसमें कहा कि बाकी सभी चिंताएं इसी रिव्यू में एक साथ उठाई जाएं। App Preview हटाना बना रहा। दोबारा विचार के अनुरोध का कोई सीधा जवाब नहीं आया।
दिन 6, शाम 7:23 बजे: चौथा मैसेज। Guideline 2.1(b) Information Needed। तकनीकी तौर पर रिजेक्शन नहीं। एक सवाल पूछने के लिए रिव्यू पर रोक। रिव्यूअर वर्ज़न से जुड़े दो IAP ढूंढ नहीं पाया और पूछा कि वे कहां मिलेंगे।
उन्होंने जो स्क्रीनशॉट लगाया, उसमें पहला पेवॉल सही दिख रहा था। दूसरा पेवॉल उसी सेटिंग्स स्क्रीन पर था, उस पहले कार्ड के ठीक नीचे वाले कार्ड पर टैप करके, जिस तक रिव्यूअर सफलता से पहुंच चुका था। मैंने सभी 11 IAP के लिए कदम-दर-कदम साफ़ नेविगेशन के साथ जवाब दिया, एक घंटे के अंदर।
दिन 7, रात 8:30 बजे: मंज़ूरी। बिल्ड पास हो गया। Pre-Order चालू हो गया। लॉन्च का हफ़्ता 11 मई के लिए तय है।
वे पांच दिन बहुत भारी थे। पीछे मुड़कर देखें तो उनमें से कोई भी अस्तित्व का सवाल नहीं था, हालांकि चक्र के बीच में ऐसा नहीं लगा। कुल देरी से लॉन्च की तारीख लगभग छूट गई थी, पर छूटी नहीं। जो प्रोडक्ट असल में लॉन्च हो रहा है, वह ठीक वही है जो सबमिशन से पहले बनाया गया था। रिव्यू पास करने के लिए कुछ भी काटा, बदला या टाला नहीं गया।
# चक्र जिन चीज़ों पर सवाल नहीं उठाता, वे भी कुछ बताती हैं
चार रिव्यू में, जिन हिस्सों को लेकर मैंने सबसे ज़्यादा चिंता की थी, उन पर कभी सवाल नहीं उठा।
आदत-स्कोर वाला फ़ीचर (छह वज़न वाले पिलर में मदद करने और नुकसान करने वाले कारकों के साथ 0-100 का स्कोर)। दवा ट्रैकिंग वाला हिस्सा (सिर्फ़ दर्ज करना, कोई सलाह वाला आउटपुट नहीं)। प्राइवेसी मॉडल (कोई अकाउंट नहीं, डेटा डिवाइस पर, साफ़ डिलीट करने के विकल्प के साथ गुमनाम ऑप्ट-इन शेयरिंग)। HealthKit में लिखना। इनमें से किसी भी हिस्से पर, यानी ऐप के उन हिस्सों पर जिनसे सेहत के दावों या प्राइवेसी की चिंता सबसे ज़्यादा उठ सकती थी, चारों में से किसी भी रिव्यू में सवाल नहीं उठा। चार स्वतंत्र रिव्यूअर, सबने देखा, और सबने इन पर सवाल न उठाने का फ़ैसला किया।
संवेदनशील कैटेगरी में ऐप बनाने वालों के लिए इसका मतलब: पहले से खुलकर बताने का काम मायने रखता है। तरीका समझाने वाले App Review Notes, ऐप के अंदर के डिस्क्लेमर, नाम सोच-समझकर चुनना, App Description में संभलकर बात रखना। इसमें कुछ भी चमकदार नहीं है। लेकिन इन सबने मिलकर लगातार चार रिव्यूअर को सबसे विवादित हिस्सों पर सवाल न उठाने की ओर ले जाने में भूमिका निभाई। 18+ एज रेटिंग, पहली बार खोलने पर डिस्क्लेमर शीट की शर्त, और ज़रूरी जगहों पर साफ़ “हम मेडिकल सलाह नहीं देते” वाला टेक्स्ट। यह सब काम आया।
इसके बजाय सवाल प्रक्रिया और मशीनी हिस्सों पर उठे। कीमत दिखाने का क्रम। बैकग्राउंड मोड की घोषणाएं। मेटाडेटा में लिंक का होना। मार्केटिंग एसेट की कंपोज़िशन। IAP का मिल पाना। ऐप के असली, ठोस हिस्से हर बार पास हुए।
# इंडी डेवलपर के लिए आखिरी बातें
कुछ बातें जो ऊपर ठीक से फ़िट नहीं हुईं।
App Store में दिखने वाले सस्ते ऐप के साथ ज़्यादा नरमी नहीं बरती जा रही। वे सालों पहले मंज़ूर हुए थे जब मानक कम थे, या उनसे वे जांच के कारण शुरू नहीं होते जो आपके गंभीर लॉन्च से होते हैं। सिस्टम कम मेहनत और कम जोखिम वाले ऐप को कम जांच से इनाम देता है। आपकी मेहनत और सावधानी ही एक वजह है कि आपका रिव्यू मुश्किल है। यह आपके ऐप की क्वालिटी पर कोई टिप्पणी नहीं है।
सिस्टम में इतने लोग नहीं हैं कि आपको वह अनुभव दे सकें जो आप चाहते हैं। App Review कॉन्ट्रैक्टरों का एक समूह है। रिव्यूअर रोज़ दर्जनों ऐप देखते हैं, हर ऐप पर कुछ मिनट। उन्हें Review Guidelines एक चेकलिस्ट की तरह सिखाई जाती हैं, किसी एक ऐप के खास UX की तरह नहीं। सहानुभूति की कमी ढांचे की है, निजी नहीं।
इंडी अनुभवों का लिखा जाना आखिरकार चीज़ें बदलता है। Apple ने पिछले दशक में App Review को काफ़ी बेहतर बनाया है। उस सुधार का कुछ हिस्सा इंडी डेवलपर के लगातार अपने अनुभव लिखने और उससे बनने वाले सामूहिक दबाव से आया है। आपके एक रिजेक्शन से किसी खास रिव्यूअर को दोबारा ट्रेनिंग नहीं मिलेगी। लेकिन इंडी अनुभवों का सधा हुआ सामूहिक रिकॉर्ड आखिरकार संस्था को बदलता है।
शायद आप वही प्रोडक्ट शिप करेंगे जो आपने बनाया। जिस भी फ़ीचर के कटने की मुझे चिंता थी, वह पूरा का पूरा शिप हुआ। चार रिजेक्शन वाला चक्र जब चल रहा था, तो अस्तित्व का सवाल लगता था। असली नतीजा मंज़ूरी पर जाकर रुका, जब तक मैं साफ़ जवाब देता रहा और लॉन्च की समय-सीमा की गुंजाइश हाथ में रखी।
अगर आप अभी चक्र के बीच में हैं और Resolution Center में रातें जाग रहे हैं: लॉन्च होगा। जवाब देते रहें। सिस्टम निजी नहीं है। प्रोडक्ट आपका है।
यह पोस्ट AlcoLog के लॉन्च का ब्योरा है, जो एक iOS ड्रिंक ट्रैकिंग ऐप है। ऊपर बताए गए चक्र के बाद, AlcoLog 11 मई 2026 को App Store पर लॉन्च हो रहा है। ऐप फ़्री है, वैकल्पिक Premium टियर के साथ, और अभी 175 देशों में प्री-ऑर्डर के लिए उपलब्ध है।
अगर आप iOS डेवलपर हैं और App Review के अनुभवों पर बात करना चाहते हैं, तो r/iOSProgramming और Indie Hackers पर इंडी-iOS कम्युनिटी शुरुआत के लिए अच्छी जगहें हैं। हम में से हर कोई जितनी बारीकी से अपने अनुभव लिखेगा, अगले व्यक्ति के लिए सामूहिक रिकॉर्ड उतना ही काम का होगा।