मुफ़्त डिज़ाइन पाएं
· Workflow · 9 मिनट पढ़ने का समय

React Native ऐप के लिए App Store स्क्रीनशॉट कैसे बनाएँ (2026)

React Native ऐप के लिए App Store स्क्रीनशॉट कैसे बनाएँ (2026)
TL;DR. React Native में कोई first-party स्क्रीनशॉट पाइपलाइन नहीं मिलती। रॉ फ्रेम कैप्चर करने के व्यावहारिक विकल्प हैं — Fastlane (iOS पर XCUITest, Android पर screengrab/Espresso), Detox (जो React Native के लिए ही बना है और तीनों में सबसे आसान है), या सिम्यूलेटर से सीधे मैनुअल कैप्चर। इनमें से जो भी चुनें, आउटपुट सिर्फ बेयर ऐप स्क्रीनशॉट होते हैं — उन्हें कैप्शन, डिवाइस फ़्रेम और लोकलाइज़्ड वेरिएंट के साथ स्टोर-रेडी कैरोसेल में बदलना एक अलग मार्केटिंग चरण है। साल में कुछ बार शिप करने वाली अधिकांश टीम के लिए, मैनुअल कैप्चर और ब्राउज़र कंपोज़िशन, Fastlane सेटअप पर एक दिन खर्च करने से बेहतर रहती है।

यह बात कोई नहीं बताता जब आप पहली बार React Native ऐप App Store पर शिप करते हैं: स्टोर के लिए ज़रूरी स्क्रीनशॉट बनाने का कोई built-in तरीका नहीं है। नेटिव iOS डेवलपर्स Xcode के UI test recorder का उपयोग करते हैं; नेटिव Android डेवलपर्स के पास बिल्ड में Espresso पहले से बना होता है। React Native दोनों के ऊपर चलता है, आपकी असली ऐप लॉजिक JavaScript में — और वह टूलिंग आपके JS के बारे में कुछ नहीं जानती। यह अंतर खुद पाटना पड़ता है।

यह पोस्ट उन तरीकों पर चलती है जो New Architecture युग (RN 0.7x और उससे ऊपर, 2026) में काम करते हैं, ठोस कमांड के साथ। हर विकल्प की लागत के बारे में ईमानदारी से बताया गया है, क्योंकि हर एक में असली कीमत है। फिर कैप्चर के बाद का हिस्सा कवर करता है — मार्केटिंग कंपोज़िशन और लोकलाइज़ेशन — जो चाहे सोर्स फ्रेम जैसे भी लिए हों, एक अलग समस्या है।

असली समस्या: कोई first-party पाइपलाइन नहीं

App Store Connect को सटीक पिक्सेल आयामों पर स्क्रीनशॉट चाहिए — आदर्श रूप से प्रति डिवाइस क्लास और प्रति समर्थित लोकेल एक सेट। Google Play के अपने आयाम हैं। नेटिव iOS प्रोजेक्ट XCUITest के ज़रिए सिम्यूलेटर को नियंत्रित करके फ्रेम डंप कर सकता है; React Native भी तकनीकी रूप से कर सकता है, लेकिन आप जो टेस्ट लिखते हैं वह नेटिव शेल के खिलाफ चलता है — कंपाइल्ड बाइनरी — आपके JavaScript कंपोनेंट के खिलाफ सीधे नहीं। आप एक ब्लैक बॉक्स को ऑटोमेट कर रहे हैं जो संयोग से आपका JS रेंडर कर रहा है।

यह अंतर जितना लगता है उससे ज़्यादा मायने रखता है। इसका मतलब है कि आपका स्क्रीनशॉट ऑटोमेशन उन वजहों से टूट सकता है जिनका आपके React कोड से कोई लेना-देना नहीं (Metro bundler नहीं चल रहा था, सिम्यूलेटर किसी परमिशन डायलॉग पर अटका, नेटिव बिल्ड आपके JS से पीछे हो गया) — और इसका मतलब है कि सीखने की लागत दो नेटिव टेस्ट फ्रेमवर्क की है, आपके जाने-पहचाने RN स्टैक की नहीं। इससे निकलने के तीन गंभीर रास्ते हैं। कितनी बार शिप करते हैं उसके आधार पर चुनें।

विकल्प 1 — Fastlane snapshot (iOS) और screengrab (Android)

Fastlane कैनोनिकल ओपन-सोर्स मोबाइल ऑटोमेशन फ्रेमवर्क है, और इसके स्क्रीनशॉट मॉड्यूल सबसे अधिक battle-tested विकल्प हैं। React Native के लिए सेट करना भी इनमें सबसे अधिक काम का है, क्योंकि ये नेटिव प्रोजेक्ट के लिए बने हैं और केवल RN को बर्दाश्त करते हैं।

iOS, snapshot के ज़रिए। आप Xcode में एक UI testing target जोड़ते हैं और Swift में XCUITest cases लिखते हैं जो ऐप को हर उस स्क्रीन तक ले जाते हैं जिसे कैप्चर करना है। fastlane snapshot init आपके fastlane/ फ़ोल्डर में एक Snapfile और एक SnapshotHelper.swift डाल देता है। टेस्ट में setupSnapshot(app) कॉल करें, ऐप लॉन्च करें, और हर स्टेट पर snapshot("01_home") कॉल करें। इसे Xcode के अंदर से नहीं — टर्मिनल से fastlane snapshot चलाएं, Xcode से सही आउटपुट नहीं आता। यह आपके Snapfile में हर सिम्यूलेटर और लोकेल पर लूप करता है और PNG fastlane/screenshots/ में लिखता है।

React Native की पेचीदगी: snapshot कंपाइल्ड ऐप लॉन्च करता है, जिसे debug मोड में Metro bundler पहले से चाहिए। इसलिए आपकी Fastfile (या एक wrapper स्क्रिप्ट) को पहले Metro शुरू करना होता है — आम तरीका है snapshot से पहले एक background tmux सेशन में npx react-native start लॉन्च करना, फिर बाद में बंद करना। Release बिल्ड जिनमें JS bundle एम्बेड हो, इससे बचते हैं लेकिन हर रन पर एक पूरा release build चाहिए।

Android, screengrab के ज़रिए। यह बिल्कुल अलग फ्रेमवर्क है: screengrab Espresso उपयोग करता है। JUnit instrumented tests में Screengrab.screenshot("name") कॉल जोड़ें, परमिशन declare करें (DISABLE_KEYGUARD, WAKE_LOCK, CHANGE_CONFIGURATION, और storage perms), ./gradlew assembleDebug assembleAndroidTest से debug APK और test APK बनाएं, और fastlane screengrab चलाएं। आउटपुट fastlane/metadata/android/ में जाता है। iOS की तरह ही, Metro और emulator पहले से चलने चाहिए — screengrab उन्हें शुरू नहीं करता।

ताकत:

  • CI-इंटीग्रेटेड और drift-proof। इसे अपनी पाइपलाइन से जोड़ें और स्क्रीनशॉट हर release build पर अपडेट होते हैं, हमेशा शिप हुए ऐप से मेल खाते हैं।
  • वास्तविक per-locale रेंडरिंग। हर लोकेल सिम्यूलेटर/emulator में अपनी असली लोकेल सेटिंग के साथ चलता है, इसलिए तारीखें, संख्याएँ और मुद्रा नेटिव रेंडर होती हैं — किसी डिज़ाइन टूल में नकली नहीं।
  • मुफ्त, ओपन सोर्स, परिपक्व। कोई सदस्यता नहीं, बड़ी कम्युनिटी, जाने-पहचाने failure modes।

कमज़ोरियाँ (खुद से ईमानदार रहें):

  • दो नेटिव टेस्ट सूट बनाए रखने होंगे। iOS के लिए Swift में XCUITest, Android के लिए Kotlin/Java में Espresso/JUnit — एक RN डेवलपर के लिए ये दोनों अपरिचित स्टैक हो सकते हैं।
  • यह नेटिव शेल टेस्ट करता है, JS लॉजिक नहीं। टेस्ट रेंडर किए गए नेटिव views पर assert करते हैं; ये आपके component tree से अनजान हैं।
  • पहली बार सेटअप में एक-दो दिन लगते हैं, और Metro bundler का झंझट CI runs में flakiness का बार-बार आने वाला कारण है।
  • आउटपुट रॉ फ्रेम हैं। कोई कैप्शन नहीं, कोई डिवाइस फ़्रेम नहीं, कोई gradient नहीं, कोई कैरोसेल नहीं — बस सिम्यूलेटर रेज़ोल्यूशन पर बेयर ऐप UI।
  • iOS के लिए Mac ज़रूरी। सिम्यूलेटर को Xcode चाहिए।

कंपोज़िशन प्रश्न पर गहरी तुलना के लिए देखें Fastlane snapshot बनाम no-code App Store स्क्रीनशॉट और Mokbi बनाम Fastlane तुलना।

विकल्प 2 — Detox स्क्रीनशॉट (React Native के लिए बना)

Detox एक gray-box end-to-end testing framework है जो Wix की टीम ने खास React Native के लिए बनाया है। अगर आप पहले से Detox e2e tests चलाते हैं, तो स्क्रीनशॉट लगभग मुफ्त हैं, और सीखने की लागत वही है जो वैसे भी उठानी है — यह एक JavaScript API है, Swift या Kotlin नहीं।

कैप्चर कॉल किसी भी टेस्ट में एक लाइन है:

// full screen
const path = await device.takeScreenshot('01_home');

// a single element
await element(by.id('paywallRoot')).takeScreenshot('paywall');

वे इमेज artifacts के रूप में रखी जाती हैं या नहीं, यह --take-screenshots flag (none, failing, manual, या all) से तय होता है और .detoxrc.js में कॉन्फ़िगर किया जाता है। manual या all मोड में, पास होने वाले टेस्ट <artifacts-location>/✓ [test name]/[name].png में लिखते हैं। Detox matchers से ऐप को हर स्टेट तक ले जाएं जो आप assertions के लिए भी उपयोग करते, फिर snapshot लें।

ताकत:

  • यह एक JS API है। टेस्ट उसी भाषा में लिखते हैं जिसमें ऐप लिखा है — कोई दूसरी भाषा का नेटिव टेस्ट सूट नहीं संभालना।
  • Gray-box होने से RN समझता है। Detox ऐप के bridge/JSI से sync करता है और idle होने का इंतज़ार करता है, जिससे स्क्रीनशॉट XCUITest के blindly-timed waits से कहीं कम flaky होते हैं।
  • एक framework, दोनों प्लेटफ़ॉर्म। एक ही टेस्ट फ़ाइल iOS और Android दोनों कैप्चर करती है।
  • शायद पहले से है। अगर आप e2e testing करते हैं, तो स्क्रीनशॉट की अतिरिक्त लागत बहुत कम है।

कमज़ोरियाँ:

  • Detox शुरू से खड़ा करना आसान नहीं है — नेटिव build config, एक dedicated test build, और emulator/simulator सेटअप। अगर पहले से नहीं चलाते, तो यह एक असली निवेश है।
  • लोकेल हैंडलिंग आप पर है। Detox snapshot के Snapfile की तरह हर App Store लोकेल अपने आप sweep नहीं करेगा; आपको लोकेल बदलाव script करने होंगे या अलग सेटिंग से relaunch करना होगा।
  • आउटपुट अभी भी रॉ फ्रेम हैं। Fastlane की तरह — बेयर ऐप UI, कोई मार्केटिंग लेयर नहीं।
  • अलग-अलग मशीनों पर स्क्रीनशॉट भिन्न हो सकते हैं (Detox का एक जाना-माना मुद्दा), जो CI में compare करने पर मायने रखता है लेकिन स्टोर assets के लिए बेहानी नहीं है।

विकल्प 3 — मैनुअल कैप्चर (सबसे सरल, और कम आंका गया)

iOS Simulator या Android emulator खोलें, अपने ऐप को हर स्क्रीन पर हाथ से ले जाएं, और फ्रेम लें। iOS पर Simulator में Cmd-S सही आकार का PNG desktop पर सेव करता है; xcrun simctl io booted screenshot home.png टर्मिनल से यही काम करता है और loosely script करना आसान है। Android पर emulator का camera बटन या adb exec-out screencap -p > home.png स्क्रीन कैप्चर करता है। फिज़िकल डिवाइस भी काम करता है — कैप्चर करें, फिर AirDrop या transfer से फ़ाइलें लें।

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

जो हिस्सा सब भूल जाते हैं: कंपोज़िशन और लोकलाइज़ेशन

तीनों विकल्पों में एक बात समान है: हर एक रॉ ऐप स्क्रीनशॉट देता है, और रॉ ऐप स्क्रीनशॉट वह नहीं है जो स्टोर में कन्वर्ट करता है। App Store कैरोसेल जो असल में इंस्टॉल बढ़ाता है उसमें स्क्रीन के चारों ओर एक डिवाइस फ़्रेम होता है, ऊपर एक-लाइन का कैप्शन फ़ायदा समझाता है, बैकग्राउंड आपके ऐप के सफेद से अलग होता है, और पाँचों पैनल में continuity होती है। ऊपर बताया कोई भी capture टूल यह कुछ नहीं बनाता — वे बेयर फ्रेम पर रुक जाते हैं। यह उनकी कमी नहीं; यह एक अलग काम है।

यहीं Mokbi फिट होता है, और सीमा के बारे में सटीक रहना ज़रूरी है: यह आपके सोर्स स्क्रीनशॉट कैप्चर नहीं करता — वह काम ऊपर बताए सिम्यूलेटर, डिवाइस, या Fastlane/Detox का है। यह उसके बाद आने वाली मार्केटिंग-कंपोज़िशन और लोकलाइज़ेशन लेयर करता है। अपने रॉ फ्रेम ब्राउज़र एडिटर में डालें, असली डिवाइस फ़्रेम में लपेटें, कैप्शन जोड़ें, मल्टी-पैनल कैरोसेल बनाएं, फिर एक क्लिक में 50 भाषाओं में कैप्शन ट्रांसलेट करें और हर स्टोर आयाम पर बैच-एक्सपोर्ट करें। डिज़ाइन वॉटरमार्क्ड प्रीव्यू के साथ मुफ्त है; असीमित एक्सपोर्ट और पब्लिशिंग एक सदस्यता के साथ आते हैं — Solo €29.99/mo (1 ऐप) या Studio €49.99/mo (अधिकतम 5 ऐप), कोई एक-बार की खरीद नहीं। यह साफ़ तरीके से फिट होता है क्योंकि यह वह समस्या हल करता है जिसे आपकी capture पाइपलाइन छूती भी नहीं: PNG के एक फ़ोल्डर को Photoshop खोले या 50 भाषाओं के लिए हाथ से resize किए बिना लोकलाइज़्ड, स्टोर-रेडी कैरोसेल में बदलना।

व्यावहारिक संयुक्त वर्कफ़्लो

  1. सोर्स फ्रेम कैप्चर करें। एक चुनें: बार-बार release के लिए CI पर Fastlane (snapshot + screengrab), अगर पहले से e2e टेस्ट चला रहे हैं तो Detox, या कम बार release के लिए मैनुअल सिम्यूलेटर कैप्चर। आउटपुट: प्रति स्क्रीन, प्रति डिवाइस रॉ PNG का एक फ़ोल्डर।
  2. कंपोज़, कैप्शन और फ्रेम करें। रॉ फ्रेम ब्राउज़र एडिटर में डालें। डिवाइस फ़्रेम जोड़ें, benefit कैप्शन लिखें, पाँच-पैनल कैरोसेल बनाएं, बैकग्राउंड चुनें।
  3. ट्रांसलेट करें। 50 भाषाओं में कैप्शन वन-क्लिक बैच-ट्रांसलेट करें, फिर आपके लिए सबसे ज़रूरी भाषाएँ हाथ से spot-check करें।
  4. बैच एक्सपोर्ट करें। App Store Connect और Google Play दोनों के लिए हर लोकेल को हर ज़रूरी आयाम पर एक pass में एक्सपोर्ट करें।
  5. अगले release पर बदलाव करें। बदले हुए फ्रेम दोबारा कैप्चर करें (Fastlane/Detox फिर चलाएं, या हाथ से लें), सेव किया हुआ प्रोजेक्ट फिर खोलें, स्क्रीनशॉट बदलें, फिर से एक्सपोर्ट करें। कैप्शन और ट्रांसलेशन का काम पहले से हो चुका है।

ऑटोमेशन कब छोड़ सकते हैं

अगर आप साल में एक से तीन release करते हैं — जो अधिकांश इंडी React Native ऐप का हाल है — तो Fastlane या Detox का सेटअप लगभग कभी ठीक नहीं बैठता। साल में दो बार दस मिनट के मैनुअल कैप्चर बचाने के लिए आप XCUITest और Metro bundler की कवायद पर एक दिन लगाएंगे। वह गणित नहीं बनती। सिम्यूलेटर से हाथ से कैप्चर करें, ब्राउज़र में कंपोज़ और लोकलाइज़ करें, और ऑटोमेशन एक बार configure करने में लगने वाले कुल समय से कम में काम हो जाएगा।

ऑटोमेशन तब सार्थक होता है जब आप साप्ताहिक या दैनिक शिप करते हैं, जब स्क्रीनशॉट का पिछड़ना बार-बार आने वाला bug बन जाए, या जब आपके पास ऐप का पोर्टफोलियो हो और प्रति-ऐप कैप्चर लागत गुणा हो जाए। उस scale पर, CI पर Fastlane (या Detox अगर पहले से स्टैक में है) capture चरण के लिए सही है — और फिर भी मार्केटिंग लेयर के लिए ब्राउज़र कंपोज़िशन टूल के साथ जोड़ते हैं, क्योंकि कोई capture पाइपलाइन तैयार कैरोसेल नहीं बनाती।

कुछ भी एक्सपोर्ट करने से पहले targets की पुष्टि करना फायदेमंद है: App Store स्क्रीनशॉट आयाम जो वास्तव में अपलोड करने हैं, और App Store स्क्रीनशॉट requirements जिनसे submissions रिजेक्ट होती हैं। इन्हें एक बार सही करना App Review के साथ एक round-trip बचाता है।

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

एडिटर खोलें →