Ücretsiz tasarımını al
· Workflow · 9 dakika okuma

React Native uygulaması için App Store ekran görüntüleri nasıl oluşturulur (2026)

React Native uygulaması için App Store ekran görüntüleri nasıl oluşturulur (2026)
TL;DR. React Native'in birinci taraf bir ekran görüntüsü hattı yoktur. Ham kareleri yakalamak için gerçekçi seçeneklerin şunlardır: Fastlane (iOS'ta XCUITest, Android'de screengrab/Espresso), Detox (React Native için özel yapılmış ve üçünün en kolayı) ya da simülatörden manuel yakalama. Hangisini seçersen seç, yalnızca ham uygulama ekran görüntüleri üretir — bunları metinler, cihaz çerçeveleri ve yerelleştirilmiş varyantlarla mağazaya hazır bir karusele dönüştürmek ayrı bir pazarlama adımıdır. Yılda birkaç kez gönderen çoğu ekip için manuel yakalama ve tarayıcı tabanlı kompozisyon, bir günlük Fastlane kurulum zahmetinden daha hızlı sonuç verir.

İlk React Native uygulamanı App Store'a gönderdiğinde sana kimsenin söylemediği şey şu: mağazanın istediği ekran görüntülerini üretmek için yerleşik bir yol yoktur. Yerel iOS geliştiricileri Xcode'un kullanıcı arayüzü test kaydedicisine başvurur; yerel Android geliştiricilerinin derleme sürecine Espresso gömülüdür. React Native her ikisinin de üzerinde çalışır; gerçek uygulama mantığın JavaScript'te çalışır — ve bu araçların hiçbiri senin JS'inin farkında değildir. Boşluğu kendin kapatmak zorunda kalırsın.

Bu yazı, New Architecture döneminde (RN 0.7x ve üzeri, 2026) gerçekten işe yarayan yaklaşımları somut komutlarla ele alıyor. Bu seçeneklerin her birinin gerçek bir maliyeti olduğu için maliyetler konusunda da dürüst. Ardından yakalamadan sonra gelen kısım ele alınıyor — pazarlama kompozisyonu ve yerelleştirme — ki bu, kaynak kareleri nasıl aldığından bağımsız olarak gerçekten ayrı bir sorundur.

Gerçek sorun: birinci taraf hat yok

App Store Connect, desteklediğin her cihaz sınıfı ve her yerel için tercihen ayrı birer set olmak üzere tam piksel boyutlarında ekran görüntüleri istiyor. Google Play kendi boyutlarını istiyor. Yerel bir iOS projesi simülatörü XCUITest aracılığıyla yönlendirebilir ve kareleri kaydedebilir; React Native de teknik olarak bunu yapabilir, ancak yazdığın test yerel kabuk — paketlenmiş ikili — üzerinde çalışır, JavaScript bileşenlerinle doğrudan etkileşime girmez. JavaScript'ini işlemeye çalışan kara bir kutuyu otomatize ediyorsundur.

Bu fark göründüğünden daha önemlidir. React kodinle hiç ilgisi olmayan nedenlerle ekran görüntüsü otomasyonunun bozulabileceği anlamına gelir (çalışmayan bir Metro bundler, izin diyaloğunda takılan bir simülatör, JS'inden sapan bir yerel derleme) ve öğrenme eğrisinin tanıdık RN yığınınla değil, iki yerel test çerçevesiyle ilgili olduğu anlamına gelir. Bu sorunun üç ciddi çözüm yolu var. Ne sıklıkta gönderdiğine göre seç.

Seçenek 1 — Fastlane snapshot (iOS) ve screengrab (Android)

Fastlane, kanonik açık kaynaklı mobil otomasyon çerçevesidir ve ekran görüntüsü modülleri en savaşta sınanmış seçenektir. Yerel projeler için yapıldığından ve React Native'i yalnızca tolere ettiğinden React Native için kurulumu da en çok iş gerektiren seçenektir.

iOS, snapshot aracılığıyla. Xcode'da bir kullanıcı arayüzü test hedefi ekler ve uygulamayı yakalamak istediğin her ekrana götüren XCUITest vakalarını Swift'te yazarsın. fastlane snapshot init, fastlane/ klasörüne bir Snapfile ve SnapshotHelper.swift bırakır. Testinde setupSnapshot(app) çağırır, başlatır ve ardından her durumda snapshot("01_home") komutunu çalıştırırsın. Bunu doğru çıktı üretmeyen Xcode içinden değil, terminalde fastlane snapshot ile çalıştırırsın. Snapfile'ındaki her simülatör ve yerel kombinasyonu üzerinde döngü yapar ve PNG'leri fastlane/screenshots/ dizinine yazar.

React Native'in yarattığı çekince: snapshot derlenmiş uygulamayı başlatır; bu uygulama debug modunda Metro bundler'ın zaten çalışıyor olmasını gerektirir. Dolayısıyla Fastfile'ın (veya bir sarmalayıcı betiğin) önce Metro'yu başlatması gerekir — yaygın çözüm, snapshot çağrısından önce arka planda bir tmux oturumunda npx react-native start çalıştırmak, ardından tamamlanınca kapatmaktır. JS paketi gömülü sürüm derlemeleri bunu önler ama çalıştırma başına tam bir sürüm derlemesine mal olur.

Android, screengrab aracılığıyla. Tamamen farklı bir çerçeve: screengrab, Espresso kullanır. JUnit enstrümantasyon testlerinin içine Screengrab.screenshot("name") çağrıları ekler, izinleri tanımlar (DISABLE_KEYGUARD, WAKE_LOCK, CHANGE_CONFIGURATION ve depolama izinleri), ./gradlew assembleDebug assembleAndroidTest ile bir debug APK ve bir test APK oluşturur ve fastlane screengrab çalıştırırsın. Çıktı fastlane/metadata/android/ dizinine iner. iOS'ta olduğu gibi Metro ve emülatörün önceden çalışıyor olması gerekir — screengrab onları senin için başlatmaz.

Güçlü yönleri:

  • CI entegrasyonu ve sapma önleme. Hattına bağla; ekran görüntüleri her sürüm derlemesinde yeniden oluşturulur, her zaman gönderilen uygulamayla örtüşür.
  • Gerçek yerel başına render. Her yerel, gerçek yerel ayarlarıyla simülatör/emülatörde çalışır; dolayısıyla tarihler, sayılar ve para birimi yerel olarak görüntülenir — bir tasarım aracında taklit edilmez.
  • Ücretsiz, açık kaynak, olgun. Abonelik yok, büyük topluluk, iyi belgelenmiş hata senaryoları.

Zayıf yönleri (kendinle dürüst ol):

  • İki yerel test paketi bakımı yapman gerekir. iOS için Swift'te XCUITest, Android için Kotlin/Java'da Espresso/JUnit — bir RN geliştiricisi olarak bu, iki yabancı yığın olabilir.
  • JS mantığını değil yerel kabuğu test eder. Testler render edilmiş yerel görünümleri doğrular; bileşen ağacından haberdar değillerdir.
  • İlk kurulum bir ila iki gün sürer ve Metro bundler dansı, kararsız CI çalışmalarının süregelen bir kaynağıdır.
  • Çıktı ham karelerdir. Metin, cihaz çerçevesi, degrade, karusel yok — yalnızca simülatör çözünürlüğünde ham uygulama arayüzü.
  • iOS için Mac gerekli. Simülatör Xcode gerektirir.

Özellikle kompozisyon konusunda ayrıntılı bir yan yana karşılaştırma için bkz. Fastlane snapshot ve kodsuz App Store ekran görüntüleri ile Mokbi ve Fastlane karşılaştırması.

Seçenek 2 — Detox ekran görüntüleri (React Native için yapılmış)

Detox, Wix ekibi tarafından React Native için özel olarak yapılmış bir gri kutu uçtan uca test çerçevesidir. Zaten e2e testler için Detox kullanıyorsan ekran görüntüleri neredeyse bedavaya gelir ve öğrenme eğrisi zaten tırmanmak isteyeceğin türdendir — Swift ya da Kotlin değil, JavaScript API'sidir.

Yakalama çağrısı herhangi bir testin içinde tek satırdır:

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

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

Bu görüntülerin artifact olarak saklanıp saklanmayacağı --take-screenshots bayrağıyla yönetilir (none, failing, manual veya all) ve .detoxrc.js içinde yapılandırılır. manual veya all modunda geçen testler <artifacts-location>/✓ [test name]/[name].png konumuna yazar. Uygulamayı her duruma Detox'un doğrulama için kullandığın aynı eşleştiricilerle götürür, ardından anlık görüntüyü alırsın.

Güçlü yönleri:

  • JavaScript API'si. Uygulamanın yazıldığı dilde test yazarsın — sahip olman gereken ikinci dilli yerel test paketi yok.
  • Gri kutu olduğu için React Native'i anlar. Detox, uygulamanın bridge/JSI'ı ile senkronize olur ve boşta kalmasını bekler; bu da ekran görüntülerini körü körüne zamanlanan XCUITest beklentilerine göre çok daha az kararsız kılar.
  • Tek çerçeve, iki platform. Aynı test dosyası hem iOS hem Android'i yakalar.
  • Muhtemelen zaten var e2e testleri yapıyorsan, ki bu durumda ekran görüntülerinin marjinal maliyeti minimumdur.

Zayıf yönleri:

  • Detox'u sıfırdan kurmak kolay değil — yerel derleme yapılandırması, özel bir test derlemesi ve emülatör/simülatör kurulumu. Halihazırda çalıştırmıyorsan bu gerçek bir yatırımdır.
  • Yerel yönetimi sana kalmış. Detox, snapshot'ın Snapfile'ının yaptığı gibi tüm App Store yerellerini otomatik olarak gezmez; yerel değişikliklerini kendin betiklersin ya da farklı ayarlarla yeniden başlatırsın.
  • Çıktı hâlâ ham karelerdir. Fastlane gibi — ham uygulama arayüzü, pazarlama katmanı yok.
  • Ekran görüntüleri farklı ana bilgisayarlarda farklı çıkabilir (bilinen bir Detox sorunu); CI'da karşılaştırdığında önemli olabilir ama mağaza varlıkları için zararsızdır.

Seçenek 3 — Manuel yakalama (en basit ve hafife alınan)

iOS Simulator'ı veya bir Android emülatörünü aç, kendi uygulamanı her ekrana el ile götür ve kareyi yakala. iOS'ta Simulator'da Cmd-S, masaüstüne doğru boyutlu bir PNG kaydeder; xcrun simctl io booted screenshot home.png aynı işi terminalden yapar ve kolayca betiklenebilir. Android'de emülatörün kamera düğmesi veya adb exec-out screencap -p > home.png ekranı yakalar. Fiziksel bir cihaz da işe yarar — yakala, ardından AirDrop'la veya dosyaları aktararak transfer et.

Bu seçenek fazla çabuk reddedilir. Sıfır kurulum gerektirir, CI olmadığı için CI'da da bozulmaz ve yılda yalnızca birkaç kez gönderen bir uygulama için gerçekten kaynak karelere ulaşmanın en hızlı yoludur. Dezavantajı açık ve gerçektir: manueldir, dolayısıyla kendi kendine yeniden oluşturmaz; bir ekranı değiştirirsen yeniden yapmana kadar yakalamalar eskir. Beş ekranlı bir karusel için sürüm başına on dakikalık iştir — yılda iki kez çalıştırdığın test otomasyonunu bakımından ucuzdur.

Herkesin unuttuğu kısım: kompozisyon ve yerelleştirme

İşte üç seçeneği birleştiren şey: hepsi ham uygulama ekran görüntüleri üretir ve ham uygulama ekran görüntüleri mağazada dönüşüm sağlayan şey değildir. Kurulum sayısını gerçekten artıran App Store karuseli, ekranın etrafında bir cihaz çerçevesi, üstünde faydayı açıklayan tek satırlık bir metin, uygulamanın beyazı olmayan bir arka plan ve beş panel boyunca tutarlılık içerir. Yukarıdaki yakalama araçlarının hiçbiri bunları üretmez — ham karede durur. Bu onların bir kusuru değildir; bu ayrı bir iştir.

İşte tam burada Mokbi devreye girer ve sınırı net koymak önemlidir: kaynak ekran görüntülerini yakalamaz — bu simülatörün, cihazın veya yukarıdaki Fastlane/Detox'un işidir. Yaptığı şey, sonraki pazarlama kompozisyonu ve yerelleştirme katmanıdır. Ham karelerini bir tarayıcı editörüne bırakır, gerçek cihaz çerçevelerine sararsın, metinler ekler, çok panelli karuseller oluşturur, ardından tek tıkla metinleri 50 dile çevirir ve her mağaza boyutunda toplu olarak dışa aktarırsın. Filigranlı bir önizlemeyle tasarım yapmak ücretsizdir; sınırsız dışa aktarma ve yayınlama bir abonelikle gelir — Solo €29.99/mo (1 uygulama) veya Studio €49.99/mo (5 uygulamaya kadar), tek seferlik satın alma yok. Temiz uyum sağlamasının nedeni, yakalama hatının çözmeye bile çalışmadığı sorunu çözmesidir: bir PNG klasörünü Photoshop açmadan veya 50 dil için elle yeniden boyutlandırmadan yerelleştirilmiş, mağazaya hazır bir karusele dönüştürmek.

Gerçekçi birleşik iş akışı

  1. Kaynak kareleri yakala. Birini seç: sık sürümler için CI'da Fastlane (snapshot + screengrab), zaten e2e testleri çalıştırıyorsan Detox ya da seyrek sürümler için manuel simülatör yakalama. Çıktı: ekran ve cihaz başına ham PNG klasörü.
  2. Kompoze et, metin ekle ve çerçeve içine al. Ham kareleri bir tarayıcı editörüne bırak. Cihaz çerçeveleri ekle, fayda metinlerini yaz, beş panelli karuseli oluştur, bir arka plan seç.
  3. Çevir. Metinleri 50 dile tek tıkla toplu çevir, ardından senin için en önemli dilleri elle kontrol et.
  4. Toplu dışa aktar. Her yerel için hem App Store Connect hem Google Play'in gerektirdiği her boyutta tek geçişte dışa aktar.
  5. Sonraki sürümde değiştir. Değişen kareleri yeniden yakala (Fastlane/Detox'u yeniden çalıştır ya da elle al), kaydedilen projeyi yeniden aç, ekran görüntülerini değiştir, yeniden dışa aktar. Metin ve çeviri işi zaten tamamdır.

Otomasyonu atlayabileceğin durumlar

Yılda bir ila üç sürüm gönderiyorsan — ki bu çoğu bağımsız React Native uygulamasını tanımlar — Fastlane veya Detox kurulum maliyeti neredeyse hiç karşılığını vermez. Yılda iki kez on dakikalık manuel yakalamadan tasarruf etmek için XCUITest ve Metro bundler dansını kurmaya bir gün harcarsın. Bu matematik tutmaz. Simülatörden elle yakala, tarayıcıda kompoze et ve yerelleştir; otomasyonu bir kez yapılandırmaktan toplam daha az zamanda işi bitirirsin.

Otomasyon, haftalık veya günlük gönderdiğinde, ekran görüntüsü sapması süregelen bir hata haline geldiğinde ya da bir uygulama portföyü çalıştırıp uygulama başına yakalama maliyetinin katlandığında kendini amorti eder. Bu ölçekte, yakalama adımı için CI'da Fastlane (veya yığınında zaten varsa Detox) doğru seçimdir — ve yine de pazarlama katmanı için bir tarayıcı kompozisyon aracıyla birleştirirsin, çünkü hiçbir yakalama hattı tamamlanmış bir karusel üretmez.

Herhangi bir şeyi dışa aktarmadan önce hedefleri teyit etmek faydalıdır: gerçekten yüklemen gereken App Store ekran görüntüsü boyutları ve başvuruların reddedilmesine yol açan App Store ekran görüntüsü gereksinimleri. Bunları bir kez doğru yapmak, App Review ile bir gidiş-dönüş turunu önler.

Sıradaki okuma

Editörü aç →