Ảnh chụp màn hình App Store với Expo: Tại sao EAS Submit bỏ qua chúng và cách triển khai nhanh (2026)

Nếu bạn ra mắt ứng dụng Expo, quy trình phát hành của bạn có thể kết thúc bằng một dòng lệnh: eas submit. Nó lấy bản build mà EAS đã tạo và chuyển đến Apple hoặc Google. Gọn gàng, nhàm chán, đáng tin. Rồi bạn mở App Store Connect để kích hoạt bản build và — các ô ảnh chụp màn hình trống rỗng. Lần nào cũng vậy.

Điều này làm nhiều người bỡ ngỡ vì EAS có cảm giác như nó làm mọi thứ. Nó build, ký, nộp. Chắc hẳn nó cũng xử lý ảnh chụp màn hình? Không phải vậy, và tài liệu nói rõ điều đó. Đây không phải bug hay tính năng thiếu bạn có thể yêu cầu — đơn giản là ngoài phạm vi của EAS Submit.

EAS Submit thực sự làm gì (và không làm gì)

EAS Submit là dịch vụ phân phối binary. Nó tải lên đúng một thứ: bản lưu trữ ứng dụng đã biên dịch — .ipa cho iOS, .aab cho Android — vào pipeline xử lý của cửa hàng. Tài liệu Expo nói rõ về ranh giới này:

"EAS Submit tải lên binary của bạn nhưng không quản lý metadata listing cửa hàng, ảnh chụp màn hình hay ghi chú phát hành."

Có một công cụ đi kèm là EAS Metadata, có thể tự động hóa một phần listing App Store của bạn — tên ứng dụng, phụ đề, mô tả đã bản địa hóa, từ khóa, URL hỗ trợ — từ một file cấu hình. Công cụ này thực sự hữu ích và đáng thiết lập. Nhưng hãy đọc kỹ phạm vi của nó: ảnh chụp màn hình không nằm trong đó. EAS Metadata đẩy văn bản, không phải hình ảnh. Ảnh chụp màn hình của bạn, trên cả hai cửa hàng, vẫn là việc bạn phải tự tạo và tải lên.

Vì vậy vấn đề ảnh chụp màn hình với Expo chia thành hai công việc riêng biệt, và việc tách biệt chúng trong đầu rất có ích:

1. Chụp — lấy frame thô của các màn hình thực trong ứng dụng từ một bản build.
2. Dựng hình & bản địa hóa — biến những frame thô đó thành các bảng marketing có khung, có chú thích, đa ngôn ngữ mà cửa hàng thực sự hiển thị.

EAS không làm cả hai. Hướng dẫn tài nguyên cửa hàng của Expo hướng bạn tự chụp frame và thiết kế các bảng trong công cụ như Figma. Hãy cùng đi qua cả hai công việc với các lệnh cụ thể.

Công việc 1: Chụp frame từ dev hoặc preview build

Bạn muốn ảnh chụp màn hình của ứng dụng thực, vì vậy bạn cần ứng dụng đang chạy ở nơi bạn có thể chụp nó. Với Expo, điều đó có nghĩa là dev client hoặc preview build — không phải Expo Go, vì Expo Go hiển thị giao diện wrapper của Expo và native config của bạn có thể khác. Build và chạy cục bộ với các lệnh Expo tiêu chuẩn:

• npx expo run:ios — prebuild native iOS, biên dịch và khởi động ứng dụng trong iOS Simulator.
• npx expo run:android — tương tự cho Android emulator (hoặc thiết bị đã kết nối).

Khi ứng dụng đang hiển thị trong iOS Simulator, chụp chỉ bằng một lệnh từ terminal Mac:

xcrun simctl io booted screenshot home.png

booted nhắm vào simulator đang chạy và ghi PNG chính xác pixel vào thư mục làm việc của bạn. Hai flag quan trọng cho việc nộp cửa hàng: --type=png (mặc định, và là gì cửa hàng muốn) và --mask=ignored so với --mask=black — mask kiểm soát liệu notch và góc bo có được render vào ảnh hay không. Để tải lên App Store, bạn thường muốn các pixel hình chữ nhật phẳng, rồi thêm khung thiết bị sau ở bước dựng hình, vì vậy chụp không mask thường là điểm khởi đầu đúng.

Trên Android, chụp thẳng từ emulator (hoặc thiết bị) bằng adb:

adb exec-out screencap -p > home.png

Dùng exec-out, không phải shell screencap. Đường dẫn shell thông thường pipe PNG qua pseudo-terminal làm hỏng binary trên một số thiết lập (bạn nhận được file bị hỏng với các ký tự carriage return thừa); exec-out truyền thẳng các byte và là dạng đáng tin. Nếu bạn chạy nhiều emulator, nhắm vào một cái với adb -s <serial> từ adb devices.

Đó là toàn bộ bộ công cụ chụp thủ công: hai lệnh, một cho mỗi nền tảng, không cần dependencies nào ngoài Xcode và Android SDK mà bạn đã có sẵn cho Expo native build.

Công việc 1, tự động hóa: Maestro hoặc Detox

Tự tay điều hướng đến đúng màn hình và chạy những lệnh đó là ổn cho một vài ảnh chụp. Khi bạn có tám màn hình trên hai loại thiết bị, hoặc muốn ảnh chụp màn hình được tái tạo trong mỗi lần phát hành để chúng không bao giờ lệch khỏi giao diện thực, bạn tự động hóa việc chụp bằng công cụ kiểm thử end-to-end có thể điều khiển ứng dụng và chụp frame.

Maestro là công cụ Expo tự nhắc đến trong các ví dụ EAS Workflows đã được ghi chép. Flow được viết bằng YAML thuần, giúp ngưỡng gia nhập thấp. Một flow điều hướng đến màn hình và chụp trông như thế này:

appId: com.you.yourapp --- - launchApp - tapOn: "Get started" - assertVisible: "Your dashboard" - takeScreenshot: dashboard

Chạy với maestro test flows/home.yaml. Lệnh takeScreenshot ghi PNG vào thư mục output của test (trỏ MAESTRO_TESTS_DIR đến bất cứ đâu bạn muốn tài nguyên lưu về). Các flow tương tự chạy trong CI trên EAS Workflows — ví dụ được Expo ghi chép build .apk với build profile e2e-test rồi chạy flow .maestro/ với nó — vì vậy bạn có thể gắn việc chụp ảnh chụp màn hình vào cùng job chạy e2e suite của bạn.

Detox là lựa chọn đã được kiểm chứng khác, với API JavaScript lập trình chặt chẽ hơn:

const path = await device.takeScreenshot('dashboard');

Hãy thành thật với bản thân về việc thiết lập Detox với Expo. Detox không chính thức hỗ trợ Expo. Trên thực tế nó hoạt động nếu bạn npx expo prebuild để tạo các native project và build một release-style client (không phải dev client) để JS bundle được nhúng vào — rồi trỏ Detox vào binary đó. Có nhiều bộ phận chuyển động hơn YAML của Maestro, và lợi ích là API đồng bộ hóa và assertion chặt chẽ hơn của Detox. Nếu bạn đã chạy Detox, tái sử dụng nó để chụp; nếu bạn đang chọn mới và mục tiêu là ảnh chụp màn hình cửa hàng, Maestro là con đường nhẹ hơn.

Công việc 1, thủ công: lựa chọn đúng khi phát hành không thường xuyên

Tự động hóa xứng đáng công sức khi bạn ra mắt thường xuyên. Nếu bạn phát hành một đến ba lần một năm — đúng với hầu hết ứng dụng Expo indie — việc thiết lập Maestro flow hoặc Detox config để chụp ảnh chụp màn hình là khoản công sức bạn bỏ ra một lần nhưng gần như không hoàn vốn. Với tần suất đó, chỉ cần:

1. Khởi động bản build bằng npx expo run:ios / run:android, điền dữ liệu demo thực tế.
2. Điều hướng đến từng màn hình chính bằng tay.
3. Chụp từng màn hình bằng lệnh simctl / adb ở trên.

Hai mươi phút nhấp chuột còn hơn nửa ngày thiết lập test harness mà bạn sẽ quên cách duy trì vào lần phát hành tiếp theo. Không có gì xấu hổ khi chụp thủ công — cửa hàng không biết PNG được tạo ra như thế nào.

Công việc 2: Dựng hình và bản địa hóa 50 ngôn ngữ

Đây là phần mà các công cụ chụp cố tình không chạm vào, và là phần cửa hàng thực sự đánh giá bạn. PNG thô từ simctl là giao diện ứng dụng trên nền trắng. Thứ xếp hạng trong tìm kiếm và chuyển đổi trên trang sản phẩm là bảng marketing: ảnh chụp màn hình bên trong khung thiết bị, trên nền có thương hiệu, với một dòng chú thích nói tại sao màn hình đó quan trọng — thường là carousel đa bảng đọc từ trái sang phải. Và trên App Store, ảnh chụp màn hình được bản địa hóa theo kích thước thiết bị và theo ngôn ngữ, vì vậy một lần ra mắt nghiêm túc là hàng chục biến thể, không chỉ năm tấm.

Đây là chỗ giới hạn Mokbi phù hợp, và đáng nói chính xác về ranh giới đó. Mokbi không chụp ảnh ứng dụng của bạn — bạn vẫn phải tạo frame nguồn bằng các lệnh Expo ở trên. Điều nó làm là lấy những frame đó và cho phép bạn, trên trình duyệt: thả chúng vào khung thiết bị thực, thêm chú thích và nền gradient, dàn dựng carousel đa bảng, dịch hàng loạt văn bản chú thích sang 50 ngôn ngữ một cú nhấp, và xuất hàng loạt mọi kích thước App Store và Play Store cùng lúc. Bạn thiết kế miễn phí với xem trước có watermark; xuất không giới hạn đi kèm vớ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. Nó thay thế bước template Figma mà hướng dẫn của Expo chỉ thoáng qua — không hơn, không kém.

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

1. Build dev/preview client. npx expo run:ios và npx expo run:android, điền dữ liệu demo tốt.
2. Chụp frame nguồn. Thủ công qua xcrun simctl io booted screenshot và adb exec-out screencap -p, hoặc tự động qua Maestro takeScreenshot / Detox device.takeScreenshot — lý tưởng là trên EAS Workflows để tái tạo mỗi lần phát hành.
3. Dựng hình các bảng marketing. Thêm khung, chú thích và sắp xếp carousel từ những frame thô đó.
4. Bản địa hóa và xuất hàng loạt. Dịch chú thích sang các ngôn ngữ mục tiêu, xuất mọi kích thước cần thiết cho cả hai cửa hàng.
5. Tải lên tài nguyên listing. Ảnh chụp màn hình vào App Store Connect và Play Console; kết hợp với EAS Metadata cho các trường văn bản nếu bạn dùng nó.
6. Nộp binary. eas submit — bước duy nhất EAS thực sự làm.
7. Lần phát hành tiếp theo: chụp lại màn hình đã thay đổi, mở lại dự án dựng hình đã lưu, hoán đổi frame, xuất lại. Chú thích và bản dịch vẫn còn nguyên.

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

Hãy dùng Maestro hoặc Detox khi sự lệch lạc ảnh chụp màn hình là chi phí thực sự: bạn ra mắt hàng tuần, giao diện thay đổi liên tục, hoặc bạn duy trì nhiều ứng dụng và không thể để ảnh cửa hàng lỗi thời. Trong những trường hợp đó, frame được tái tạo trên CI xứng đáng công sức và câu chuyện công cụ ảnh chụp màn hình React Native (mà Expo kế thừa) đáng để đầu tư.

Với tất cả những người còn lại — những ai phát hành mỗi quý — hãy bỏ qua. Chụp thủ công bằng hai lệnh terminal, rồi dựng hình và bản địa hóa trên trình duyệt, giúp bạn có một listing đã bản địa hóa hoàn chỉnh chỉ trong một buổi chiều mà không cần bảo trì gì giữa các lần phát hành. Hãy chọn công cụ phù hợp với tần suất của bạn, không phải thứ trông ấn tượng trên CI dashboard.

Dù thế nào, phần binary đã được giải quyết: eas submit lo phần đó. Hãy đảm bảo bạn kiểm tra ảnh chụp màn hình theo yêu cầu cửa hàng hiện tại trước khi tải lên — Apple từ chối listing vì lệch một pixel — và phần còn lại của lần ra mắt chỉ là design.

Đọc tiếp

• Dành cho Expo developers
• Ảnh chụp màn hình App Store với React Native
• So sánh: Mokbi vs Fastlane
• 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 →