2026-07-04 · Workflow · 9 menit baca

Cara membuat tangkapan layar App Store untuk aplikasi React Native (2026)

TL;DR. React Native tidak memberikan pipeline tangkapan layar bawaan. Pilihan realistismu untuk mengambil frame mentah adalah Fastlane (XCUITest di iOS, screengrab/Espresso di Android), Detox (yang dibuat khusus untuk RN dan paling mudah dari ketiganya), atau sekadar pengambilan manual dari simulator. Pilihan mana pun yang kamu ambil hanya menghasilkan tangkapan layar aplikasi mentah — mengubahnya menjadi korsel siap toko dengan teks, bingkai perangkat, dan varian yang dilokalisasi adalah langkah marketing terpisah. Untuk kebanyakan tim yang merilis beberapa kali setahun, pengambilan manual ditambah komposisi berbasis browser mengalahkan satu hari setup Fastlane.

Ini yang tidak diberitahu siapa pun saat kamu merilis aplikasi React Native pertamamu ke App Store: tidak ada cara bawaan untuk menghasilkan tangkapan layar yang diminta toko. Developer iOS native menggunakan UI test recorder Xcode; developer Android native punya Espresso yang sudah terintegrasi dalam build. React Native berdiri di atas keduanya, dengan logika aplikasimu yang berjalan di JavaScript — dan tidak ada dari tooling itu yang tahu JS-mu ada. Kamu harus menjembatani celah ini sendiri.

Artikel ini membahas pendekatan yang benar-benar berhasil di era New Architecture (RN 0.7x ke atas, 2026), dengan perintah konkret. Jujur tentang biayanya, karena setiap pilihan ini memiliki biaya nyata. Kemudian membahas bagian yang datang setelah pengambilan — komposisi marketing dan lokalisasi — yang merupakan masalah yang sungguh-sungguh terpisah terlepas dari cara kamu mengambil frame sumber.

Masalah sebenarnya: tidak ada pipeline bawaan

App Store Connect menginginkan tangkapan layar dengan dimensi piksel yang tepat, idealnya satu set per kelas perangkat dan satu set per lokal yang kamu dukung. Google Play menginginkan ukurannya sendiri. Proyek iOS native bisa menjalankan simulator melalui XCUITest dan membuang frame; React Native secara teknis juga bisa, tapi pengujian yang kamu tulis berjalan terhadap native shell — binary yang dikompilasi — bukan terhadap komponen JavaScript-mu secara langsung. Kamu mengotomasi kotak hitam yang kebetulan merender JS-mu.

Perbedaan itu lebih berarti dari yang kedengarannya. Artinya otomasi tangkapan layarmu rusak karena alasan yang tidak ada hubungannya dengan kode React-mu (Metro bundler yang tidak berjalan, simulator yang macet di dialog izin, build native yang menyimpang dari JS-mu) dan artinya kurva belajarnya adalah kurva dua framework pengujian native, bukan stack RN yang sudah kamu kenal. Ada tiga cara serius untuk melewati ini. Pilih berdasarkan seberapa sering kamu merilis.

Opsi 1 — Fastlane snapshot (iOS) dan screengrab (Android)

Fastlane adalah framework otomasi mobile open-source yang paling banyak digunakan, dan modul tangkapan layarnya adalah opsi yang paling teruji. Tapi juga paling banyak pekerjaan untuk diatur di React Native, karena dibuat untuk proyek native dan hanya bisa menoleransi RN.

iOS, melalui snapshot. Kamu menambahkan target UI testing di Xcode dan menulis kasus XCUITest dalam Swift yang mengarahkan aplikasi ke setiap layar yang ingin kamu tangkap. fastlane snapshot init menempatkan Snapfile dan SnapshotHelper.swift ke folder fastlane/-mu. Dalam pengujianmu, kamu memanggil setupSnapshot(app), meluncurkan, lalu snapshot("01_home") di setiap kondisi. Kamu menjalankannya dari terminal dengan fastlane snapshot — bukan dari dalam Xcode, yang tidak akan menghasilkan output yang benar. Ia mengulang setiap simulator dan lokal dalam Snapfile-mu dan menulis PNG ke fastlane/screenshots/.

Kerumitan React Native: snapshot meluncurkan aplikasi yang dikompilasi, yang dalam mode debug memerlukan Metro bundler yang sudah berjalan. Jadi Fastfile-mu (atau skrip wrapper) harus memulai Metro terlebih dahulu — trik umum adalah meluncurkan npx react-native start dalam sesi tmux di latar belakang sebelum memanggil snapshot, lalu menghentikannya setelahnya. Build rilis dengan bundle JS yang tertanam menghindari ini tapi memerlukan build rilis penuh setiap kali.

Android, melalui screengrab. Framework yang sama sekali berbeda: screengrab menggunakan Espresso. Kamu menambahkan panggilan Screengrab.screenshot("name") di dalam JUnit instrumented tests, mendeklarasikan izin (DISABLE_KEYGUARD, WAKE_LOCK, CHANGE_CONFIGURATION, dan izin storage), membangun debug APK dan test APK dengan ./gradlew assembleDebug assembleAndroidTest, dan menjalankan fastlane screengrab. Output tersimpan di fastlane/metadata/android/. Seperti iOS, Metro dan emulator harus sudah aktif — screengrab tidak memulainya untukmu.

Kelebihan:

Terintegrasi dengan CI dan tahan drift. Sambungkan ke pipeline-mu dan tangkapan layar diperbarui di setiap build rilis, selalu cocok dengan aplikasi yang dikirim.
Rendering per lokal yang nyata. Setiap lokal berjalan di simulator/emulator dengan pengaturan lokal aktualnya, sehingga tanggal, angka, dan mata uang dirender secara native — tidak dipalsukan di alat desain.
Gratis, open source, matang. Tidak ada langganan, komunitas besar, mode kegagalan yang sudah dipahami.

Kekurangan (jujurlah dengan dirimu sendiri):

Kamu harus mengelola dua suite pengujian native. XCUITest dalam Swift untuk iOS, Espresso/JUnit dalam Kotlin/Java untuk Android — sebagai developer RN, itu bisa jadi dua stack yang asing.
Ini menguji native shell, bukan logika JS-mu. Pengujian mengecek native view yang dirender; mereka tidak mengenal pohon komponen-mu.
Setup butuh satu atau dua hari pertama kali, dan urusan Metro bundler adalah sumber flaky CI yang berulang.
Output adalah frame mentah. Tidak ada teks, tidak ada bingkai perangkat, tidak ada gradien, tidak ada korsel — hanya UI aplikasi mentah di resolusi simulator.
Butuh Mac untuk iOS. Simulator memerlukan Xcode.

Untuk perbandingan lebih mendalam khusus tentang pertanyaan komposisi, lihat Fastlane snapshot vs tangkapan layar App Store tanpa kode dan perbandingan Mokbi vs Fastlane.

Opsi 2 — Tangkapan layar Detox (dibuat untuk React Native)

Detox adalah framework pengujian end-to-end gray-box yang dibuat khusus untuk React Native, oleh tim di Wix. Jika kamu sudah menjalankan Detox untuk pengujian e2e, tangkapan layar hampir gratis, dan kurva belajarnya adalah yang memang ingin kamu panjat — ini adalah API JavaScript, bukan Swift atau Kotlin.

Pemanggilan pengambilan gambar hanya satu baris di dalam pengujian mana pun:

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

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

Apakah gambar tersebut disimpan sebagai artefak diatur oleh flag --take-screenshots (none, failing, manual, atau all) dan dikonfigurasi di .detoxrc.js. Dalam mode manual atau all, pengujian yang lulus menulis ke <artifacts-location>/✓ [test name]/[name].png. Kamu mengarahkan aplikasi ke setiap kondisi dengan matcher Detox yang sama yang kamu gunakan untuk assertion, lalu ambil snapshot.

Kelebihan:

Ini adalah API JS. Kamu menulis pengujian dalam bahasa yang sama dengan bahasa aplikasimu — tidak perlu suite pengujian native dalam bahasa kedua.
Gray-box, sehingga memahami RN. Detox menyinkronkan dengan bridge/JSI aplikasi dan menunggu hingga idle, sehingga tangkapan layar jauh lebih stabil daripada XCUITest dengan jeda waktu yang buta.
Satu framework, dua platform. File pengujian yang sama mengambil iOS dan Android.
Kemungkinan sudah kamu punya jika kamu melakukan pengujian e2e, dan kalau begitu biaya tambahan untuk tangkapan layar sangat kecil.

Kekurangan:

Menyiapkan Detox dari nol tidak mudah — konfigurasi build native, build pengujian khusus, dan setup emulator/simulator. Jika kamu belum menjalankannya, ini investasi nyata.
Penanganan lokal ada di tanganmu. Detox tidak secara otomatis menyapu setiap lokal App Store seperti yang dilakukan snapshot dengan Snapfile-nya; kamu harus membuat skrip perubahan lokal atau meluncurkan ulang dengan pengaturan berbeda.
Output tetap frame mentah. Sama seperti Fastlane — UI aplikasi mentah, tanpa lapisan marketing.
Tangkapan layar bisa berbeda di mesin host yang berbeda (masalah Detox yang sudah diketahui), yang penting jika kamu membandingkannya di CI tapi tidak berpengaruh untuk aset toko.

Opsi 3 — Pengambilan manual (paling sederhana, dan sering diremehkan)

Buka iOS Simulator atau emulator Android, arahkan aplikasimu sendiri ke setiap layar secara manual, dan ambil frame-nya. Di iOS, Cmd-S di Simulator menyimpan PNG dengan ukuran yang benar ke desktop; xcrun simctl io booted screenshot home.png melakukan hal yang sama dari terminal dan mudah diotomasi secara longgar. Di Android, tombol kamera emulator atau adb exec-out screencap -p > home.png mengambil layar. Perangkat fisik juga bisa — ambil, lalu AirDrop atau transfer file-nya.

Ini terlalu cepat dikesampingkan. Setup-nya nol, tidak pernah rusak di CI karena memang tidak ada CI, dan untuk aplikasi yang merilis segelintir kali setahun ini adalah jalur tercepat yang sungguh-sungguh untuk mendapatkan kumpulan frame sumber. Kekurangannya jelas dan nyata: ini manual, jadi tidak diperbarui sendiri, dan jika kamu mengubah layar maka tangkapan layarmu kedaluwarsa sampai kamu mengulanginya. Untuk korsel lima layar, itu sepuluh menit pekerjaan per rilis — lebih murah daripada memelihara otomasi pengujian yang kamu jalankan dua kali setahun.

Bagian yang sering dilupakan semua orang: komposisi dan lokalisasi

Inilah yang menyatukan ketiga opsi: setiap satu dari mereka menghasilkan tangkapan layar aplikasi mentah, dan tangkapan layar aplikasi mentah bukan yang mengkonversi di toko. Korsel App Store yang benar-benar mendorong instalasi memiliki bingkai perangkat di sekitar layar, satu baris teks di atasnya yang menjelaskan manfaatnya, latar yang bukan warna putih aplikasimu, dan kesinambungan di seluruh lima panel. Tidak ada alat pengambilan di atas yang menghasilkan hal itu — mereka berhenti di frame mentah. Itu bukan cacat pada mereka; itu adalah pekerjaan yang berbeda.

Inilah langkah di mana Mokbi masuk, dan penting untuk tepat tentang batasannya: ia tidak mengambil tangkapan layar sumbermu — itu adalah simulator, perangkat, atau Fastlane/Detox di atas. Yang dilakukannya adalah lapisan komposisi marketing dan lokalisasi yang datang setelahnya. Kamu menjatuhkan frame mentahmu ke editor berbasis browser, membungkusnya dalam bingkai perangkat nyata, menambahkan teks, menata korsel multi-panel, lalu satu klik menerjemahkan teks ke 50 bahasa dan mengekspor massal di setiap dimensi toko. Gratis untuk mendesain dengan pratinjau bertanda air; ekspor dan publikasi tanpa batas hadir dengan langganan — Solo €29.99/mo (1 aplikasi) atau Studio €49.99/mo (hingga 5 aplikasi), tanpa pembelian sekali bayar. Alasannya cocok masuk dengan bersih adalah karena ia menyelesaikan masalah yang bahkan tidak dicoba oleh pipeline pengambilanmu: mengubah folder PNG menjadi korsel yang dilokalisasi dan siap toko tanpa membuka Photoshop atau mengubah ukuran secara manual untuk 50 bahasa.

Alur kerja kombinasi yang realistis

Ambil frame sumber. Pilih salah satu: Fastlane (snapshot + screengrab) di CI untuk rilis yang sering, Detox jika kamu sudah menjalankan pengujian e2e, atau pengambilan manual dari simulator untuk rilis yang jarang. Output: folder PNG mentah per layar, per perangkat.
Susun, tambahkan teks, dan bingkai. Masukkan frame mentah ke editor berbasis browser. Tambahkan bingkai perangkat, tulis teks manfaat, bangun korsel lima panel, pilih latar belakang.
Terjemahkan. Terjemahkan teks secara massal satu klik ke 50 bahasa, lalu periksa bahasa yang paling penting bagimu secara manual.
Ekspor massal. Ekspor setiap lokal di setiap dimensi yang diperlukan untuk App Store Connect dan Google Play dalam satu kali proses.
Ganti di rilis berikutnya. Ambil ulang frame yang berubah (jalankan ulang Fastlane/Detox, atau ambil secara manual), buka kembali proyek yang tersimpan, ganti tangkapan layar, ekspor ulang. Pekerjaan teks dan terjemahan sudah selesai.

Kapan kamu bisa melewati otomasi

Jika kamu merilis satu hingga tiga kali setahun — yang menggambarkan kebanyakan aplikasi React Native indie — biaya setup Fastlane atau Detox hampir tidak pernah terbayar. Kamu akan menghabiskan satu hari menyiapkan XCUITest dan urusan Metro bundler untuk menghemat sepuluh menit pengambilan manual dua kali setahun. Hitungannya tidak masuk akal. Ambil dari simulator secara manual, susun dan lokalisasi di browser, dan kamu selesai dalam total waktu yang lebih sedikit dari waktu yang dibutuhkan otomasi untuk dikonfigurasi satu kali.

Otomasi terbayar ketika kamu merilis setiap minggu atau setiap hari, ketika drift tangkapan layar menjadi bug yang berulang, atau ketika kamu mengelola portofolio aplikasi dan biaya pengambilan per aplikasi berlipat ganda. Pada skala itu, Fastlane di CI (atau Detox jika sudah ada di stack-mu) adalah pilihan yang tepat untuk langkah pengambilan — dan kamu tetap memadukanya dengan alat komposisi berbasis browser untuk lapisan marketing, karena tidak ada pipeline pengambilan yang menghasilkan korsel yang sudah selesai.

Sebelum mengekspor apa pun, ada baiknya mengonfirmasi targetnya: ukuran tangkapan layar App Store yang benar-benar perlu kamu unggah, dan persyaratan tangkapan layar App Store yang membuat pengiriman ditolak. Mendapatkan ini dengan benar sekali menghemat bolak-balik dengan App Review.

Bacaan selanjutnya

Buka editor →