Cách tạo ảnh chụp màn hình App Store cho ứng dụng React Native (2026)

Đây là điều không ai nói với bạn khi bạn ra mắt ứng dụng React Native đầu tiên lên App Store: không có cách nào tích hợp sẵn để tạo ra các ảnh chụp màn hình mà cửa hàng yêu cầu. Các developer iOS thuần dùng trình ghi UI test của Xcode; developer Android thuần có Espresso tích hợp sẵn trong build. React Native nằm ở trên cả hai, với logic ứng dụng thực chạy trong JavaScript — và không công cụ nào trong số đó biết JS của bạn tồn tại. Bạn phải tự mình lấp đầy khoảng trống đó.

Bài viết này đi qua các cách tiếp cận thực sự hoạt động trong kỷ nguyên New Architecture (RN 0.7x trở lên, 2026), với các lệnh cụ thể. Bài viết trung thực về chi phí, vì mỗi lựa chọn đều có chi phí thực. Sau đó đề cập đến phần sau khi chụp — dựng hình marketing và bản địa hóa — đây là một vấn đề hoàn toàn riêng biệt bất kể bạn lấy frame nguồn bằng cách nào.

Vấn đề thực sự: không có pipeline chính thức

App Store Connect muốn ảnh chụp màn hình ở kích thước pixel chính xác, lý tưởng là một bộ cho mỗi loại thiết bị và một bộ cho mỗi locale bạn hỗ trợ. Google Play có các kích thước riêng của mình. Một dự án iOS thuần có thể điều khiển simulator qua XCUITest và xuất frame; React Native về mặt kỹ thuật cũng có thể, nhưng test bạn viết chạy trên native shell — binary được đóng gói — không phải trực tiếp trên các component JavaScript của bạn. Bạn đang tự động hóa một hộp đen tình cờ đang render JS của bạn.

Sự phân biệt đó quan trọng hơn vẻ ngoài của nó. Nghĩa là tự động hóa ảnh chụp màn hình của bạn bị hỏng vì những lý do không liên quan đến React code của bạn (Metro bundler chưa chạy, simulator bị kẹt ở hộp thoại quyền, một native build bị lệch khỏi JS của bạn) và nghĩa là learning curve là curve của hai native test framework, không phải stack RN quen thuộc của bạn. Có ba cách nghiêm túc để giải quyết điều này. Chọn dựa trên tần suất bạn ra mắt.

Lựa chọn 1 — Fastlane snapshot (iOS) và screengrab (Android)

Fastlane là framework tự động hóa mobile mã nguồn mở chuẩn mực, và các module ảnh chụp màn hình của nó là lựa chọn được kiểm chứng nhất. Nhưng chúng cũng tốn công nhất để thiết lập cho React Native, vì chúng được xây dựng cho các dự án thuần và chỉ hỗ trợ RN một cách miễn cưỡng.

iOS, qua snapshot. Bạn thêm một UI testing target trong Xcode và viết các XCUITest case bằng Swift để điều khiển ứng dụng đến từng màn hình muốn chụp. fastlane snapshot init tạo ra Snapfile và SnapshotHelper.swift vào thư mục fastlane/ của bạn. Trong test bạn gọi setupSnapshot(app), khởi chạy, rồi snapshot("01_home") tại mỗi trạng thái. Bạn chạy từ terminal với fastlane snapshot — không phải từ bên trong Xcode, vì Xcode không tạo ra output đúng. Nó lặp qua từng simulator và locale trong Snapfile của bạn và ghi PNG vào fastlane/screenshots/.

Điểm khó với React Native: snapshot khởi chạy ứng dụng đã biên dịch, vốn ở debug cần Metro bundler đã chạy sẵn. Vì vậy Fastfile của bạn (hoặc một wrapper script) phải khởi động Metro trước — thủ thuật phổ biến là khởi chạy npx react-native start trong một phiên tmux nền trước khi gọi snapshot, rồi dọn dẹp sau. Release build với JS bundle được nhúng sẵn tránh được điều này nhưng tốn một full release build mỗi lần chạy.

Android, qua screengrab. Framework hoàn toàn khác: screengrab dùng Espresso. Bạn thêm các lệnh Screengrab.screenshot("name") bên trong JUnit instrumented test, khai báo permissions (DISABLE_KEYGUARD, WAKE_LOCK, CHANGE_CONFIGURATION, và storage perms), build debug APK và test APK bằng ./gradlew assembleDebug assembleAndroidTest, rồi chạy fastlane screengrab. Output nằm trong fastlane/metadata/android/. Giống iOS, Metro và emulator phải đã sẵn sàng — screengrab không khởi động chúng cho bạn.

Điểm mạnh:

• Tích hợp CI và không bị lệch. Kết nối vào pipeline và ảnh chụp màn hình được tái tạo trong mỗi lần release build, luôn khớp với ứng dụng đã ra mắt.
• Render thực sự theo từng locale. Mỗi locale chạy trong simulator/emulator với cài đặt locale thực tế, nên ngày tháng, số và tiền tệ hiển thị đúng theo từng vùng — không phải giả lập trong design tool.
• Miễn phí, mã nguồn mở, trưởng thành. Không cần đăng ký, cộng đồng lớn, các lỗi hay gặp đã được ghi chép rõ.

Điểm yếu (hãy thành thật với bản thân):

• Bạn phải duy trì hai native test suite. XCUITest bằng Swift cho iOS, Espresso/JUnit bằng Kotlin/Java cho Android — với tư cách developer RN, đó có thể là hai stack không quen thuộc.
• Test chạy trên native shell, không phải JS logic của bạn. Các test kiểm tra trên native view đã render; chúng không nhận biết component tree của bạn.
• Thiết lập mất một đến hai ngày lần đầu, và vũ điệu Metro bundler là nguồn gốc thường xuyên của các CI run không ổn định.
• Output là frame thô. Không có chú thích, không có khung thiết bị, không có gradient, không có carousel — chỉ là giao diện ứng dụng thuần ở độ phân giải simulator.
• Cần Mac cho iOS. Simulator cần Xcode.

Để so sánh chi tiết hơn về câu hỏi dựng hình, xem fastlane snapshot vs ảnh chụp màn hình App Store không cần code và so sánh Mokbi vs Fastlane.

Lựa chọn 2 — Detox screenshots (được xây dựng cho React Native)

Detox là một gray-box end-to-end testing framework được tạo ra riêng cho React Native, bởi đội ngũ tại Wix. Nếu bạn đã chạy Detox cho e2e test, ảnh chụp màn hình gần như miễn phí, và learning curve là curve bạn muốn leo dù sao — đây là JavaScript API, không phải Swift hay Kotlin.

Lệnh chụp chỉ một dòng bên trong bất kỳ test nào:

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

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

Việc các ảnh đó có được lưu làm artifact hay không được điều khiển bởi flag --take-screenshots (none, failing, manual, hoặc all) và được cấu hình trong .detoxrc.js. Ở chế độ manual hoặc all, các test pass sẽ ghi vào <artifacts-location>/✓ [test name]/[name].png. Bạn điều khiển ứng dụng đến từng trạng thái với các Detox matcher giống như bạn dùng cho assertion, rồi snapshot.

Điểm mạnh:

• Đây là JavaScript API. Bạn viết test bằng ngôn ngữ ứng dụng của mình — không có native test suite ngôn ngữ thứ hai để quản lý.
• Gray-box, nên hiểu được RN. Detox đồng bộ với bridge/JSI của ứng dụng và chờ cho đến khi ứng dụng idle, khiến ảnh chụp màn hình ít bị lỗi hơn nhiều so với XCUITest timed blindly.
• Một framework, cả hai nền tảng. Cùng một file test chụp cả iOS và Android.
• Bạn có thể đã có nó nếu bạn làm e2e testing, trong đó chi phí biên của ảnh chụp màn hình là rất nhỏ.

Điểm yếu:

• Thiết lập Detox từ đầu không hề đơn giản — cấu hình native build, dedicated test build, và thiết lập emulator/simulator. Nếu bạn chưa chạy nó, đây là khoản đầu tư thực sự.
• Xử lý locale là do bạn. Detox không tự động quét mọi locale App Store như Snapfile của snapshot; bạn phải script thay đổi locale hoặc khởi động lại với cài đặt khác.
• Output vẫn là frame thô. Giống Fastlane — giao diện ứng dụng thuần, không có lớp marketing.
• Ảnh chụp màn hình có thể khác nhau giữa các máy host (một vấn đề đã biết của Detox), quan trọng nếu bạn so sánh chúng trong CI nhưng không ảnh hưởng gì đối với tài nguyên store.

Lựa chọn 3 — Chụp thủ công (đơn giản nhất, và bị đánh giá thấp)

Mở iOS Simulator hoặc Android emulator, tự điều khiển ứng dụng đến từng màn hình, và chụp frame. Trên iOS, Cmd-S trong Simulator lưu PNG đúng kích thước ra desktop; xcrun simctl io booted screenshot home.png làm điều tương tự từ terminal và dễ script lỏng. Trên Android, nút camera của emulator hoặc adb exec-out screencap -p > home.png chụp màn hình. Thiết bị vật lý cũng dùng được — chụp rồi AirDrop hoặc chuyển file.

Cách này bị bỏ qua quá nhanh. Nó không cần thiết lập gì, không bao giờ hỏng trong CI vì không có CI, và với ứng dụng ra mắt vài lần một năm đây thực sự là con đường nhanh nhất để có bộ frame nguồn. Nhược điểm rõ ràng và có thực: nó là thủ công, nên không tự tái tạo, và nếu bạn thay đổi một màn hình các ảnh chụp sẽ lỗi thời cho đến khi bạn làm lại. Với một carousel năm màn hình, đó là mười phút việc mỗi lần ra mắt — rẻ hơn việc duy trì tự động hóa test bạn chạy hai lần một năm.

Phần mọi người quên: dựng hình và bản địa hóa

Đây là điểm chung của cả ba lựa chọn: tất cả chúng đều tạo ra ảnh chụp màn hình ứng dụng thô, và ảnh chụp màn hình ứng dụng thô không phải thứ chuyển đổi tốt trong cửa hàng. Carousel App Store thực sự thúc đẩy cài đặt có khung thiết bị quanh màn hình, một dòng chú thích ở trên giải thích lợi ích, nền không phải màu trắng của ứng dụng, và sự liên kết xuyên suốt năm bảng. Không công cụ chụp nào ở trên tạo ra bất kỳ thứ nào trong số đó — chúng dừng lại ở frame thuần. Đó không phải là lỗi của chúng; đó là một công việc khác.

Đây là bước Mokbi phù hợp, và đáng nói rõ về ranh giới: nó không chụp ảnh chụp màn hình nguồn của bạn — đó là simulator, thiết bị, hoặc Fastlane/Detox ở trên. Điều nó làm là lớp dựng hình marketing và bản địa hóa đến tiếp theo. Bạn thả frame thô vào trình chỉnh sửa trình duyệt, bọc chúng trong khung thiết bị thực, thêm chú thích, dàn dựng carousel đa bảng, rồi dịch hàng loạt chú thích sang 50 ngôn ngữ và xuất hàng loạt ở mọi kích thước cửa hàng chỉ một cú nhấp. Miễn phí để thiết kế với xem trước có watermark; xuất không giới hạn và đăng tải đi kèm với gói đăng ký — Solo €29.99/mo (1 ứng dụng) hoặc Studio €49.99/mo (tối đa 5 ứng dụng), không mua một lần. Lý do nó phù hợp là nó giải quyết vấn đề mà pipeline chụp của bạn thậm chí không cố gắng: biến một thư mục PNG thành một carousel đã bản địa hóa, sẵn sàng đăng tải mà không cần mở Photoshop hay resize thủ công cho 50 ngôn ngữ.

Quy trình kết hợp thực tế

1. Chụp frame nguồn. Chọn một: Fastlane (snapshot + screengrab) trên CI cho các lần ra mắt thường xuyên, Detox nếu bạn đã chạy e2e test, hoặc chụp simulator thủ công cho các lần ra mắt ít thường xuyên. Output: một thư mục PNG thô cho mỗi màn hình, mỗi thiết bị.
2. Dựng hình, thêm chú thích và khung. Thả frame thô vào trình chỉnh sửa trình duyệt. Thêm khung thiết bị, viết chú thích lợi ích, xây dựng carousel năm bảng, chọn nền.
3. Dịch. Dịch hàng loạt chú thích sang 50 ngôn ngữ một cú nhấp, rồi kiểm tra tay các ngôn ngữ quan trọng nhất với bạn.
4. Xuất hàng loạt. Xuất mọi locale ở mọi kích thước yêu cầu cho cả App Store Connect và Google Play trong một lần.
5. Hoán đổi lại trong lần ra mắt tiếp theo. Chụp lại frame đã thay đổi (chạy lại Fastlane/Detox, hoặc chụp tay), mở lại dự án đã lưu, hoán đổi ảnh chụp màn hình, xuất lại. Công việc chú thích và dịch đã xong rồi.

Khi bạn có thể bỏ qua tự động hóa

Nếu bạn ra mắt một đến ba lần một năm — mô tả đúng hầu hết ứng dụng React Native indie — chi phí thiết lập Fastlane hay Detox gần như không bao giờ hoàn vốn. Bạn sẽ tốn một ngày kết nối XCUITest và vũ điệu Metro bundler để tiết kiệm mười phút chụp thủ công hai lần một năm. Phép tính đó không đóng lại. Chụp tay từ simulator, dựng hình và bản địa hóa trên trình duyệt, và bạn xong trong tổng thời gian ít hơn thời gian tự động hóa sẽ cần để cấu hình một lần.

Tự động hóa xứng đáng với công sức khi bạn ra mắt hàng tuần hoặc hàng ngày, khi sự lệch lạc ảnh chụp màn hình trở thành bug thường xuyên, hoặc khi bạn quản lý một danh mục ứng dụng và chi phí chụp mỗi ứng dụng nhân lên. Ở quy mô đó, Fastlane trên CI (hoặc Detox nếu đã có trong stack) là lựa chọn đúng cho bước chụp — và bạn vẫn kết hợp với công cụ dựng hình trình duyệt cho lớp marketing, vì không pipeline chụp nào tạo ra carousel hoàn chỉnh.

Trước khi xuất bất cứ thứ gì, đáng xác nhận các mục tiêu: kích thước ảnh chụp màn hình App Store bạn thực sự cần tải lên, và yêu cầu ảnh chụp màn hình App Store khiến các bài nộp bị từ chối. Làm đúng một lần tiết kiệm một vòng với App Review.

Đọc tiếp

• Dành cho React Native developers
• So sánh: Mokbi vs Fastlane
• fastlane snapshot vs ảnh chụp màn hình App Store không cần code
• Kích thước ảnh chụp màn hình App Store
• Yêu cầu ảnh chụp màn hình App Store

Mở trình chỉnh sửa →