बिना नए ऐप वर्जन के आप क्या बदल सकते हैं: Apple बनाम Google
स्टोर लिस्टिंग को छूने से पहले, एक सवाल जानना ज़रूरी है: क्या यह एडिट आपको पूरी सबमिशन में डालेगा, या यह चुपचाप लाइव हो जाएगा? इसे गलत समझें तो या तो आप एक ऐसी रिव्यू क्यू में फंस जाते हैं जिसका आपने बजट नहीं रखा था, या फिर आप मान लेते हैं कि बदलाव लाइव है जबकि वह अभी भी अप्रूवल का इंतज़ार कर रहा होता है। दोनों स्टोर इस सवाल का जवाब उलटे तरीकों से देते हैं, और यही फ़र्क दोनों जगह लिस्टिंग को सिंक रखने को झंझट भरा बनाता है।
यहाँ ईमानदार, फ़ील्ड-दर-फ़ील्ड वर्ज़न है — पहले मैट्रिक्स, फिर हर स्टोर के नियमों के पीछे की वजह ताकि आप उन मामलों का अंदाज़ा लगा सकें जो यह टेबल साफ़ नहीं बताती।
मैट्रिक्स
हर आम लिस्टिंग फ़ील्ड, और उसे बदलने पर हर स्टोर क्या मांगता है। "नया वर्जन / रिलीज़" का मतलब है कि स्टोर उस एडिट को एक सबमिशन का हिस्सा मानता है जो आपको भेजनी पड़ती है; "रिव्यूड" का मतलब है कि लाइव होने से पहले कोई इंसान या ऑटोमेटेड जांच चलती है।
| ऐप आइकन | प्राइमरी आइकन बाइनरी में शिप होता है — इसे बदलने के लिए नई बिल्ड चाहिए। उस बिल्ड के साथ रिव्यूड। | स्टोर आइकन एक लिस्टिंग एसेट है। नई रिलीज़ नहीं चाहिए। रिव्यूड। |
दो बातें तुरंत सामने आती हैं। Apple लगभग सबकुछ एक वर्जन रिकॉर्ड से गुज़ारता है। Google पूरी लिस्टिंग को अपने आप चलने देता है। कोई भी स्टोर उन एसेट्स पर रिव्यू नहीं छोड़ता जो मायने रखते हैं — लगभग हर सेल में "रिव्यूड" शब्द दिखता है। तो असली सवाल शायद ही कभी "क्या इसका रिव्यू होगा" होता है, यह ज़्यादा "क्या यह एडिट अपने साथ एक सबमिशन खींच लाता है" होता है।
Apple: नया वर्जन रिकॉर्ड नई बिल्ड जैसा नहीं है
यही वह फ़र्क है जो लोगों को उलझा देता है। App Store पर, अपने स्क्रीनशॉट, नाम, सबटाइटल, कीवर्ड फ़ील्ड या डिस्क्रिप्शन को एडिट करने से लिस्टिंग का एक नया वर्जन बनता है। सुनने में यह ऐसा लगता है कि इससे आपको वापस Xcode जाना पड़ेगा। पर ऐसा नहीं है। Apple आपके मौजूदा मेटाडेटा को अपने आप नए वर्जन में ले जाता है, और सिर्फ़-मेटाडेटा वाले बदलाव के लिए नए ऐप कोड की ज़रूरत नहीं होती — आप एक बिल्ड अटैच करते हैं (App Store Connect वर्जन पर फिर भी एक बिल्ड मांगता है) और ऐप क्या करता है उसमें कुछ नहीं बदलते। आप क्यू में मौजूद फ़ील्ड्स एडिट करते हैं, सबमिट करते हैं, और एक ही रिव्यू साइकल सबको कवर कर लेता है।
तो "नया कोड नहीं, पर फिर भी रिव्यूड" इसे याद रखने का सटीक तरीका है। न कंपाइल स्टेप, न नए फ़ीचर — पर एडिट फिर भी App Review में जाता है और पब्लिक होने से पहले अपनी बारी का इंतज़ार करता है। अपने बदलाव इकट्ठा रखें: क्योंकि एक ही वर्जन रिकॉर्ड में नए स्क्रीनशॉट, दोबारा लिखा डिस्क्रिप्शन, नया सबटाइटल और अपडेटेड कीवर्ड्स एक साथ आ सकते हैं, इसलिए हर एक पर अलग रिव्यू साइकल खर्च करने की कोई वजह नहीं है।
ऐप आइकन इसका अपवाद है जिसके लिए वाकई बिल्ड चाहिए। आपका प्राइमरी आइकन बाइनरी में बेक्ड होता है और वहीं से लिया जाता है, इसलिए सचमुच का नया आइकन मतलब नई बिल्ड। ऑल्टरनेट आइकन के लिए भी यही सच है — उन्हें इस्तेमाल होने लायक बनने के लिए ऐप में बंडल होना पड़ता है, तो एक जोड़ना बिल्ड है, लिस्टिंग एडिट नहीं।
Apple के दो एस्केप हैच
प्रोमोशनल टेक्स्ट। यह वह एक फ़ील्ड है जिसे आप बिना वर्जन और बिना रिव्यू के बदल सकते हैं। यह 170 कैरेक्टर का है, डिस्क्रिप्शन के ऊपर बैठता है, और जब चाहें तब अपडेट हो जाता है — सेल, लॉन्च नोट, या समय-संवेदनशील कॉपी के लिए काम का। यह सर्च रैंकिंग को प्रभावित नहीं करता और किसी सबमिशन का हिस्सा नहीं है, यही वजह है कि यह स्टोर पर सबसे तेज़ बदलने वाली चीज़ है। अगर आपको आज ही कुछ लाइव चाहिए, तो यही फ़ील्ड यह कर सकती है।
Product Page Optimization. PPO आपको अपने लाइव प्रोडक्ट पेज के मुक़ाबले अपने स्क्रीनशॉट, App Preview और आइकन के तीन तक ट्रीटमेंट टेस्ट करने देता है — बिना नया ऐप वर्जन शिप किए। विज़ुअल बदलने में Apple इससे ज़्यादा किसी सामान्य सबमिशन से बाहर नहीं जाता। दो सावधानियाँ इसे ईमानदार रखती हैं: ट्रीटमेंट मेटाडेटा फिर भी टेस्ट चलने से पहले अप्रूव होना चाहिए (यानी यह रिव्यूड है, इंस्टेंट नहीं), और जो भी आइकन आप टेस्ट करना चाहते हैं वह पहले से मौजूदा ऐप बाइनरी का हिस्सा होना चाहिए। PPO यह बदलता है कि विज़िटर क्या देखते हैं; यह रिव्यू को नहीं छोड़ता।
Google Play: बिना रिलीज़ के लिस्टिंग पब्लिश करना
Play इसका उलटा काम करता है। आपकी स्टोर लिस्टिंग — टाइटल, शॉर्ट डिस्क्रिप्शन, फ़ुल डिस्क्रिप्शन, स्क्रीनशॉट, फ़ीचर ग्राफ़िक, आइकन, प्रोमो वीडियो — बिना किसी नई ऐप रिलीज़ जोड़े अपने आप एडिटेबल और पब्लिशेबल है। आप एडिट करते हैं, और वे Publishing overview में रिव्यू के लिए भेजने-लायक बदलावों में दिखते हैं। आप उन्हें भेजते हैं, वे Google के रिव्यू से गुज़रते हैं, और किसी भी बिल्ड से स्वतंत्र होकर लाइव हो जाते हैं।
इसे बढ़ा-चढ़ाकर न समझने के लिए कुछ बातें सटीक रखनी होंगी। बदलाव फिर भी रिव्यूड होते हैं — Play का रिव्यू लिस्टिंग एडिट्स पर भी चलता है, और ऐप नाम व आइकन जैसे तत्वों की जांच होती है, यानी यह चुपचाप इंस्टेंट स्वैप नहीं है। और लिस्टिंग किसी शिप हुए ऐप से अलग होकर मुक्त नहीं तैर सकती — Play को एडिट करने लायक पब्लिक लिस्टिंग होने के लिए पहले एक रिलीज़ चाहिए। जो कभी रिलीज़ ही नहीं हुआ, उसके लिए आप स्टैंडअलोन स्टोर पेज नहीं पुश कर सकते। मैनेज्ड पब्लिशिंग एक और बात जोड़ती है जो जानना ज़रूरी है — अगर यह ऑन है, तो अप्रूव्ड बदलाव तब तक रुके रहते हैं जब तक आप खुद उन्हें एक्टिव रूप से पब्लिश नहीं करते, जो एक फ़ीचर है, देरी नहीं, एक बार जब आप इसे जान लें।
यह असंतुलन, और यह आपका समय क्यों खाता है
दोनों मॉडल को साथ रखें तो फ़र्क साफ़ दिखता है। Apple लगभग हर टेक्स्ट और इमेज एडिट को एक वर्जन रिकॉर्ड और रिव्यू पास से बांधता है, प्रोमोशनल टेक्स्ट और PPO ही इससे बचने के इकलौते रास्ते हैं। Google लिस्टिंग को रिलीज़ से पूरी तरह अलग कर देता है, बदलावों का रिव्यू करता है, और जब तक ऐप पहले से मौजूद है, उन्हें अपनी सुविधा के हिसाब से शिप करता है।
यह असंतुलन तब चुपचाप महंगा पड़ता है जब आप दोनों स्टोर चलाते हैं। वही स्क्रीनशॉट रिफ्रेश एक स्टोर पर वर्जन-रिकॉर्ड सबमिशन है और दूसरे पर स्टैंडअलोन लिस्टिंग अपडेट। डिस्क्रिप्शन का दोबारा लिखा जाना Apple पर एक रिव्यूड वर्जन है और Google पर एक रिव्यूड लिस्टिंग बदलाव। कंटेंट वही रहता है; मैकेनिक्स नहीं, तो जो बदलाव Play पर एक ही काम है वह App Store पर अलग काम बन जाता है — और एक को शिप करते हुए दूसरे को भूल जाना, या यह मान लेना कि कुछ Apple पर लाइव है जबकि वह अभी भी रिव्यू में है, आसान है।
Mokbi यहाँ कहाँ फिट होता है
यह क्रॉस-स्टोर असंतुलन ही असली वजह है कि एक पब्लिशिंग टूल अपनी कीमत वसूल करता है। Mokbi की शुरुआत एक स्क्रीनशॉट एडिटर के रूप में हुई थी, पर एक लिस्टिंग साथ में टेक्स्ट और इमेज है — तो यह एक ही जगह दोनों स्टोर के लिए स्क्रीनशॉट सेट डिज़ाइन करता है और लिस्टिंग कॉपी का ड्राफ़्ट बनाता है: App Store का नाम, सबटाइटल, कीवर्ड फ़ील्ड और डिस्क्रिप्शन; Play का टाइटल, शॉर्ट डिस्क्रिप्शन और फ़ुल डिस्क्रिप्शन। आपको वे फ़ील्ड मिलते हैं जिन्हें हर स्टोर वाकई इंडेक्स करता है, उस स्टोर के हिसाब से ढले हुए, न कि टेक्स्ट का एक ब्लॉक जिसे आप दो बार पेस्ट करते हैं।
फिर यह पूरी लिस्टिंग — स्क्रीनशॉट और कॉपी दोनों — को 50 भाषाओं में ट्रांसलेट करता है, ताकि एक बार किया गया बदलाव हर मार्केट में सही फ़ील्ड में पहुंचे, न कि किसी ऐसी लिस्टिंग में अंग्रेज़ी में अटका रहे जो बाकी हर जगह लोकलाइज़्ड है। और यह पब्लिश करता है: Mokbi तैयार लिस्टिंग को Play Developer API के ज़रिए सीधे Google Play पर पुश करता है, और App Store Connect में उसे सबमिट के लिए तैयार करके रखता है — Apple फिर भी अपनी तरफ़ से आख़िरी Submit और रिव्यू पास मांगता है, जो कि Apple का नियम है और ठीक वही क्रॉस-स्टोर असंतुलन है जिसके बारे में यह पूरी पोस्ट है। वही आख़िरी रिव्यू भी है जहाँ से इस पोस्ट में बताई गई घड़ी टिकनी शुरू होती है।