अपना मुफ़्त डिज़ाइन पाएँ
· Publishing · 6 मिनट रीड

fastlane के बिना अपनी App Store लिस्टिंग पब्लिश करना

fastlane के बिना अपनी App Store लिस्टिंग पब्लिश करना
TL;DR. fastlane के deliver और supply कमांड-लाइन से आपका मेटाडेटा, स्क्रीनशॉट्स और बाइनरी दोनों स्टोर्स पर पुश करते हैं — मुफ़्त, ओपन सोर्स, और अगर CI में जोड़ लें तो हमेशा अप-टू-डेट। कीमत यह है कि किसी को वह पाइपलाइन बनानी और मेंटेन करनी पड़ती है: Ruby, Xcode या Gradle, एक Fastfile, और UI-टेस्ट का रखरखाव। अगर आप पाइपलाइन नहीं चलाना चाहते, तो नो-कोड रास्ते हैं स्टोर के वेब कंसोल, सीधे स्टोर APIs, या ऐसा टूल जो लिस्टिंग आपके लिए ड्राफ़्ट कर दे। Mokbi वह नो-कोड रास्ता है जो वाकई पब्लिश करता है: यह आपके स्क्रीनशॉट्स और फ़ीचर ग्राफ़िक डिज़ाइन करता है, पूरी लिस्टिंग लिखता है और 50 भाषाओं में अनुवाद करता है, और उसे Play Developer API के ज़रिए सीधे Google Play पर पुश करता है, जबकि App Store वर्शन को App Store Connect में तैयार करके रखता है ताकि आप सबमिट कर सकें। न कोई Ruby, न Xcode, न UI टेस्ट।

fastlane का डिफ़ॉल्ट जवाब होना बेवजह नहीं है। यह एक मुफ़्त, MIT-लाइसेंस्ड टूलकिट है, और इसका deliver एक्शन (उर्फ़ upload_to_app_store) एक ही कमांड में स्क्रीनशॉट्स, App Preview वीडियो, मेटाडेटा और बाइनरी को App Store Connect पर अपलोड कर देता है। Android की तरफ़, supply (उर्फ़ upload_to_play_store) Google Play के लिए वही काम करता है — मेटाडेटा, स्क्रीनशॉट्स और APK या app bundle। इन्हें CI से चलाएं और हर रिलीज़ पर आपकी लिस्टिंग खुद बन जाती है, ऐप से कभी अलग नहीं होती।

तो असली सवाल यह नहीं कि "क्या fastlane अच्छा है" — है ही। सवाल यह है कि क्या आप वह पाइपलाइन खुद संभालना चाहते हैं जो इसे अच्छा बनाती है, या बिना पाइपलाइन के लिस्टिंग अपडेट करना चाहते हैं।

deliver और supply असल में क्या करते हैं

दोनों असल में official स्टोर APIs के ऊपर बने wrappers हैं। पर्दे के पीछे, fastlane वही कॉल्स करता है जो आप खुद कर सकते हैं।

  • deliver (iOS)। ऐप का नाम, विवरण, कीवर्ड्स, रिलीज़ नोट्स, URLs, कैटेगरी और रिव्यू जानकारी अपलोड करता है, साथ में लोकलाइज़्ड स्क्रीनशॉट्स और preview वीडियो। बाइनरी Apple के iTMSTransporter से जाती है; मेटाडेटा App Store Connect API से। यह अपलोड के बाद रिव्यू के लिए सबमिट भी कर सकता है।
  • supply (Android)। मेटाडेटा, स्क्रीनशॉट्स और APK या AAB को Google Play पर अपलोड करता है, एक track चुनता है और बिल्ड्स को प्रमोट करता है। ध्यान रहे: अपलोड किए स्क्रीनशॉट्स किसी locale के मौजूदा स्क्रीनशॉट्स में जुड़ते नहीं, बल्कि उनकी जगह ले लेते हैं।

दोनों API keys से authenticate होते हैं — Apple के लिए एक App Store Connect API key, Google के लिए एक service-account JSON — तो एक बार सेट होने के बाद ये CI में बिना निगरानी चलते रहते हैं। यही पूरा आकर्षण है: मेटाडेटा और स्क्रीनशॉट्स कोड की तरह, आपके repo में वर्ज़न्ड, हर बिल्ड पर शिप।

fastlane की असली कीमत

fastlane इंस्टॉल और चलाने के लिए मुफ़्त है। कीमत सेटअप और रखरखाव में है, और वह इंजीनियरिंग समय में चुकानी पड़ती है।

  • चलाने के लिए एक रनटाइम। fastlane एक Ruby टूलचेन है (Ruby 3.0+), आमतौर पर Bundler से मैनेज होती है। iOS के काम के लिए Mac पर Xcode चाहिए; Android के लिए Gradle पक्ष। यह इंस्टॉल करने और पैच रखने के लिए वाकई मशीनरी है।
  • लिखने के लिए कॉन्फ़िग फ़ाइलें। एक Fastfile आपके lanes तय करती है; एक Deliverfile या Android का मेटाडेटा फ़ोल्डर लिस्टिंग डीटेल्स रखता है। पहला काम करता वर्शन सही करने में आमतौर पर एक-दो दिन लगते हैं।
  • खड़ा करने के लिए CI। यह ऑटोमेशन तभी फ़ायदा देता है जब पाइपलाइन में हो, यानी API keys, सिग्निंग सीक्रेट्स, और एक बिल्ड रनर, जिसे सेट कर के हरा-भरा रखना है।
  • अगर इस्तेमाल करें, तो स्क्रीनशॉट कैप्चर का रखरखाव। fastlane का snapshot हर locale के स्क्रीनशॉट्स के लिए सिम्युलेटर में UI टेस्ट चलाता है। ये टेस्ट नाज़ुक होते हैं: आम शिकायत है कि सेटअप कुछ महीने ठीक चलता है, फिर कोई UI बदलाव flow तोड़ देता है और टेस्ट कोड को नई स्टेट्स के हिसाब से फिर से लिखना पड़ता है। snapshot डिफ़ॉल्ट रूप से flaky रन को दोबारा try करता है, जो नेटवर्क- और डेटा-आधारित अनिश्चितता को ठीक नहीं करता, बस छुपा देता है। और raw आउटपुट में न कैप्शन होते हैं न बैकग्राउंड — टीमें अक्सर डिज़ाइन किसी और टूल में ही पूरा करती हैं।

इसमें से कुछ भी टूल की बुराई नहीं है। यह एक ईमानदार ट्रेड-ऑफ़ है: fastlane एक बार-बार होने वाले मैनुअल काम को कोड में बदल देता है, और बदले में आप कोड मेंटेन करते हैं। साप्ताहिक शिप करने वाली टीम के लिए, जिसमें एक इंजीनियर रिलीज़ ऑटोमेशन संभालता हो, यह अच्छी डील है। लेकिन साल में कुछ ही बार लिस्टिंग अपडेट करने वाले सोलो मेकर या PM के लिए, पाइपलाइन को ज़िंदा रखने की कीमत उससे ज़्यादा हो सकती है जितना यह बचाती है।

fastlane के बिना लिस्टिंग अपडेट करना

अगर आप fastlane छोड़ देते हैं, तो भी मेटाडेटा और स्क्रीनशॉट्स स्टोर्स तक पहुँचाने के तीन तरीके बचते हैं।

1. स्टोर के वेब कंसोल

सबसे सीधा रास्ता। App Store Connect में आप हर localization को हाथ से एडिट करते हैं और स्क्रीनशॉट्स को display-size स्लॉट्स में डालते हैं; Google Play Console में आप हर भाषा के लिए स्टोर लिस्टिंग एडिट करते हैं और वहीं स्क्रीनशॉट्स अपलोड करते हैं। कोई कोड नहीं, कोई keys नहीं, मेंटेन करने को कुछ नहीं — बस पॉइंट करें और क्लिक करें। नुकसान यह है कि यह पूरी तरह मैनुअल है, और कई locales में एक-एक स्क्रीन करते जाना धीमा और गलती-प्रवण है। एक-दो भाषाओं के लिए ठीक; 20 पर तकलीफ़देह।

2. सीधे स्टोर APIs

दोनों स्टोर वही APIs एक्सपोज़ करते हैं जिन्हें fastlane कॉल करता है, तो आप fastlane का Ruby स्टैक अपनाए बिना इनके खिलाफ़ स्क्रिप्ट लिख सकते हैं। Apple का App Store Connect API एक REST API है, जो एक छोटी-अवधि के JWT (ES256, आपकी key से साइन किया गया) से authenticate होता है, और इसमें स्क्रीनशॉट सेट बनाने, इमेज बाइट्स रिज़र्व-अपलोड करने और मेटाडेटा पैच करने के endpoints हैं। Google का Play Developer API एक "edits" मॉडल इस्तेमाल करता है — आप एक edit खोलते हैं, लिस्टिंग्स और इमेजेज़ बदलते हैं, फिर उसे commit करते हैं। इससे आपको पूरा कंट्रोल मिलता है और यह किसी कस्टम इंटरनल डैशबोर्ड में फ़िट बैठता है, लेकिन अब वह इंटीग्रेशन आप खुद लिखते और मेंटेन करते हैं। यह पूरी fastlane पाइपलाइन से छोटी commitment है, ज़ीरो नहीं।

3. एक मैनेज्ड टूल जो लिस्टिंग ड्राफ़्ट करे

दूसरा नो-कोड रास्ता है ऐसा टूल जो आपके लिए लिस्टिंग तैयार करे, ताकि बस उसे स्टोर पर पहुँचाना बाकी रह जाए। यहाँ ट्रेड-ऑफ़ पलट जाता है: पाइपलाइन संभालने वाले इंजीनियर की बजाय, एक PM या डिज़ाइनर सीधे ब्राउज़र में लिस्टिंग खुद संभालता है। आप CI ऑटोमेशन को छोड़कर बदले में इंजीनियर की ज़रूरत ही खत्म कर रहे हैं।

Mokbi कहाँ फ़िट बैठता है — ईमानदारी से

Mokbi fastlane की CI कहानी को रिप्लेस करने की कोशिश नहीं करता। अगर आपका लक्ष्य है कि हर बिल्ड से बिना किसी इंसान के स्क्रीनशॉट्स खुद बनें, तो fastlane पाइपलाइन ही सही टूल है और वह मुफ़्त है। हम उस दूसरी स्थिति के लिए हैं: वह व्यक्ति जो Ruby, Xcode, Fastfile या UI टेस्ट को छुए बिना एक निखरी हुई लिस्टिंग शिप करना चाहता है।

ब्राउज़र में आप स्क्रीनशॉट्स डिज़ाइन करते हैं, स्टोर टेक्स्ट ड्राफ़्ट करते हैं, और पूरी लिस्टिंग को 50 भाषाओं में अनुवाद करते हैं — न कोई सिम्युलेटर, न CI, न कोड। एक डिज़ाइनर या PM पूरी मार्केटिंग सतह को शुरू से अंत तक अकेले संभाल सकता है।

यह रहा वह आख़िरी मील, और Mokbi उसे कवर करता है। यह स्क्रीनशॉट्स और फ़ीचर ग्राफ़िक डिज़ाइन करता है, पूरी लिस्टिंग लिखता और 50 भाषाओं में अनुवाद करता है, फिर नतीजे को Play Developer API के ज़रिए सीधे Google Play पर पुश करता है और App Store वर्शन को App Store Connect में तैयार रखता है, ताकि आप बस Submit दबा सकें — वह आख़िरी Submit और उसका रिव्यू Apple खुद ज़रूरी बनाता है, यह Apple का नियम है, हमारी तरफ़ की कमी नहीं। वही endpoints जो fastlane कॉल करता है, बस पाइपलाइन के बिना।

कब क्या चुनें

  • हर हफ़्ते शिप करते हैं, इंजीनियर है, ज़ीरो drift चाहिए? fastlane। यह मुफ़्त है, ऑटोमेटेड है, और स्क्रीनशॉट्स-मेटाडेटा को ऐप के साथ बिल्कुल तालमेल में रखता है। इसे कोई नहीं हरा सकता।
  • साल में कुछ ही बार लिस्टिंग अपडेट करते हैं, CI की गुंजाइश नहीं? वेब कंसोल, या ऐसा टूल जो लिस्टिंग ड्राफ़्ट कर दे। इस रफ़्तार पर पाइपलाइन का रखरखाव इसके लायक नहीं।
  • प्रोग्रामैटिक कंट्रोल चाहिए पर fastlane का स्टैक नहीं? सीधे App Store Connect और Play Developer APIs कॉल करें।
  • चाहते हैं कि कोई डिज़ाइनर या PM कई भाषाओं में लिस्टिंग अकेले संभाले? ब्राउज़र से ड्राफ़्ट करें, अनुवाद करें, पब्लिश करें — Mokbi Google Play पर पुश करता है और App Store वर्शन को आपके सबमिट के लिए तैयार रखता है।

fastlane एक मुफ़्त, ऑटोमेटेड और स्थापित विकल्प के तौर पर अपनी जगह ख़ुद कमाता है। नो-कोड रास्ता "बेहतर" नहीं है — यह एक अलग ट्रेड है: आप CI ऑटोमेशन छोड़ देते हैं, और बदले में किसी को लिस्टिंग अपडेट करने के लिए पाइपलाइन बनानी या संभालनी नहीं पड़ती।

आगे क्या पढ़ें

एडिटर खोलें →