ภาพหน้าจอ App Store สำหรับ Expo: ทำไม EAS Submit ถึงไม่จัดการภาพหน้าจอ และวิธีส่งงานได้เร็ว (2026)

ถ้าคุณส่งแอป Expo เส้นทาง release ของคุณน่าจะจบลงด้วยบรรทัดเดียว: eas submit มันนำ build ที่ EAS สร้างแล้วส่งไปให้ Apple หรือ Google เรียบร้อย น่าเบื่อ น่าเชื่อถือ จากนั้นคุณเปิด App Store Connect เพื่อปล่อย build — และช่องภาพหน้าจอว่างเปล่า ทุกครั้ง

หลายคนสะดุดกับเรื่องนี้เพราะ EAS ดูเหมือนทำ ทุกอย่าง มัน build มัน sign มัน submit แล้วมันจัดการภาพหน้าจอด้วยไหม? ไม่ และ doc ก็พูดชัดเจน นี่ไม่ใช่ bug หรือ feature ที่หายไปที่คุณจะ flag ได้ — มันแค่อยู่นอกขอบเขตของ EAS Submit

EAS Submit ทำอะไรได้ (และไม่ได้) กันแน่

EAS Submit คือบริการส่ง binary มันอัปโหลดสิ่งเดียว: ไฟล์ archive แอปที่ compile แล้ว — .ipa สำหรับ iOS, .aab สำหรับ Android — เข้าสู่ pipeline ประมวลผลของ store เอกสาร Expo ระบุขอบเขตนี้ไว้ชัดเจน:

"EAS Submit อัปโหลด binary ของคุณแต่ไม่จัดการ metadata ของ store listing ภาพหน้าจอ หรือ release notes"

มีเครื่องมือพี่น้องชื่อ EAS Metadata ที่ สามารถ อัตโนมัติบางส่วนของ App Store listing ได้ — ชื่อแอป subtitle คำอธิบายที่แปลเป็นภาษาท้องถิ่น keywords URL สนับสนุน — จากไฟล์ config มีประโยชน์จริงและคุ้มค่าตั้งค่า แต่อ่านขอบเขตให้ดี: ภาพหน้าจอไม่รวมอยู่ EAS Metadata ดัน ข้อความ ไม่ใช่รูปภาพ ภาพหน้าจอของคุณทั้งสอง store ยังต้องผลิตและอัปโหลดเอง

ดังนั้นปัญหาภาพหน้าจอของ Expo แยกออกเป็นสองงานที่ต่างกัน และช่วยได้มากถ้าแยกมันออกจากกันในหัว:

1. ถ่ายภาพ — ดึง frame แบบ raw ของหน้าจอจริงของแอปออกจาก build
2. จัดวาง & แปลภาษา — นำ frame แบบ raw เหล่านั้นมาสร้างเป็นพาเนลทางการตลาดที่มีกรอบ คำบรรยาย หลายภาษา ที่ store แสดงจริง

EAS ไม่ทำทั้งสอง คำแนะนำของ Expo เกี่ยวกับ store assets ชี้ให้คุณถ่าย frame เองและออกแบบพาเนลในเครื่องมืออย่าง Figma มาดูทั้งสองงานพร้อม command ที่เป็นรูปธรรม

งานที่ 1: ถ่าย frame จาก dev หรือ preview build

คุณต้องการภาพหน้าจอของแอปจริง ดังนั้นต้องมีแอปรันอยู่ในที่ที่ถ่ายได้ สำหรับ Expo นั่นหมายถึง dev client หรือ preview build — ไม่ใช่ Expo Go เพราะ Expo Go แสดง UI ของ Expo wrapper และ native config ของคุณอาจต่างกัน Build และรันในเครื่องด้วย command Expo มาตรฐาน:

• npx expo run:ios — prebuild native iOS, compile และเปิดแอปใน iOS Simulator
• npx expo run:android — เหมือนกันสำหรับ Android emulator (หรืออุปกรณ์ที่เชื่อมต่อ)

เมื่อแอปขึ้นบนหน้าจอใน iOS Simulator การถ่ายภาพทำได้ด้วย command เดียวจาก Mac terminal:

xcrun simctl io booted screenshot home.png

booted กำหนดเป้า simulator ที่รันอยู่และเขียน PNG แบบ pixel-exact ไปยัง working directory ปัจจุบัน มี flag สองตัวที่สำคัญสำหรับ store: --type=png (ค่าเริ่มต้น และที่ store ต้องการ) และ --mask=ignored กับ --mask=black — mask ควบคุมว่า notch และมุมโค้งจะ render ลงในภาพหรือไม่ สำหรับการอัปโหลด App Store โดยทั่วไปต้องการพิกเซล rectangular แบบ flat แล้วเพิ่มกรอบอุปกรณ์ทีหลังในขั้นตอนจัดวาง ดังนั้นการถ่ายแบบไม่มี mask มักเป็นจุดเริ่มต้นที่ถูก

บน Android ถ่ายตรงจาก emulator (หรืออุปกรณ์) ด้วย adb:

adb exec-out screencap -p > home.png

ใช้ exec-out ไม่ใช่ shell screencap เส้นทาง shell ธรรมดา pipe PNG ผ่าน pseudo-terminal ที่บิดเบือน binary ในบางการตั้งค่า (ได้ไฟล์เสียที่มี carriage return แปลกๆ); exec-out stream byte ตรงและเป็นรูปแบบที่เชื่อถือได้ ถ้ารัน emulator หลายตัว กำหนดเป้าด้วย adb -s <serial> จาก adb devices

นั่นคือ toolkit การถ่ายแบบ manual ทั้งหมด: สอง command หนึ่งต่อแพลตฟอร์ม ไม่มี dependency นอกจาก Xcode และ Android SDK ที่มีอยู่แล้วสำหรับ Expo native build

งานที่ 1 แบบอัตโนมัติ: Maestro หรือ Detox

การแตะไปยังหน้าจอที่ถูกต้องและรัน command เหล่านั้นด้วยมือเหมาะสำหรับภาพจำนวนน้อย แต่เมื่อมีแปดหน้าจอข้ามสองคลาสอุปกรณ์ หรือต้องการภาพหน้าจอที่สร้างใหม่ทุก release เพื่อให้ตรงกับ UI จริงเสมอ คุณก็ต้อง automate การถ่ายด้วยเครื่องมือ end-to-end testing ที่ขับแอป และ ถ่าย frame ได้

Maestro คือตัวที่ Expo เองใช้ในตัวอย่าง EAS Workflows ที่ document ไว้ Flow เป็น YAML ธรรมดา ทำให้ barrier ต่ำ flow ที่ขับไปยังหน้าจอและถ่ายภาพหน้าตาประมาณนี้:

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

รันด้วย maestro test flows/home.yaml command takeScreenshot เขียน PNG ไปยัง test output directory (กำหนด MAESTRO_TESTS_DIR ไปยังที่ที่ต้องการให้ asset อยู่) flow เดียวกันรันใน CI บน EAS Workflows — ตัวอย่างที่ Expo document ไว้ build .apk ด้วย build profile e2e-test แล้วรัน flow .maestro/ กับมัน — ดังนั้นเชื่อมการถ่ายภาพหน้าจอเข้ากับ job เดียวกับที่รัน e2e suite ได้

Detox เป็นอีกตัวเลือกที่มั่นคง พร้อม JavaScript API ที่ programmatic กว่า:

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

แต่ต้องซื่อสัตย์กับตัวเองเรื่องการตั้งค่า Detox กับ Expo Detox ไม่ได้รองรับ Expo อย่างเป็นทางการ ในทางปฏิบัติทำงานได้ถ้า npx expo prebuild เพื่อสร้าง native project และ build client แบบ release-style (ไม่ใช่ dev client) เพื่อให้ JS bundle ฝังอยู่ — จากนั้นชี้ Detox ไปยัง binary นั้น มีส่วนประกอบที่ต้องจัดการมากกว่า YAML ของ Maestro และสิ่งที่ได้คือ synchronization และ assertion API ที่เข้มงวดกว่าของ Detox ถ้ารัน Detox อยู่แล้ว ใช้มันถ่ายภาพได้เลย ถ้าเลือกใหม่และเป้าหมายคือภาพหน้าจอ store Maestro คือเส้นทางที่เบากว่า

งานที่ 1 แบบ manual: ทางเลือกที่เหมาะสำหรับ release ที่ไม่บ่อย

Automation คุ้มค่าเมื่อส่งงานบ่อย ถ้าออก release หนึ่งถึงสามครั้งต่อปี — ซึ่งตรงกับแอป Expo indie ส่วนใหญ่ — การตั้งค่า Maestro flow หรือ Detox config สำหรับการถ่ายภาพหน้าจอเป็นงานที่จ่ายครั้งเดียวและแทบไม่คืนทุน สำหรับจังหวะนั้น แค่:

1. Boot build ด้วย npx expo run:ios / run:android ใส่ demo data ที่สมจริง
2. ไปยังแต่ละหน้าจอหลัก ด้วยมือ
3. ถ่ายแต่ละหน้าจอ ด้วย command simctl / adb ข้างต้น

คลิกยี่สิบนาทีดีกว่าครึ่งวันกับ test harness ที่จะลืมวิธี maintain ตอน release ถัดไป ไม่มีอะไรน่าอายกับการถ่ายแบบ manual — store ไม่รู้ว่า PNG สร้างมาอย่างไร

งานที่ 2: การจัดวางและการแปลเป็น 50 ภาษา

นี่คือส่วนที่เครื่องมือถ่ายภาพจงใจไม่แตะ และเป็นส่วนที่ store ให้คะแนนคุณจริงๆ PNG จาก simctl แบบ raw คือ UI แอปบนพื้นหลังสีขาว สิ่งที่อยู่ในอันดับสูงในการค้นหาและเปลี่ยนผู้ใช้ในหน้า product คือพาเนล ทางการตลาด: ภาพหน้าจอในกรอบอุปกรณ์ บนพื้นหลัง branded มีคำบรรยายหนึ่งบรรทัดอธิบายว่าทำไมหน้าจอนั้นสำคัญ — มักเป็นคารูเซลหลายพาเนลที่อ่านจากซ้ายไปขวา และบน App Store ภาพหน้าจอจะ localize ตามขนาดอุปกรณ์และตามภาษา ดังนั้น launch ที่จริงจังคือหลายสิบ variant ไม่ใช่แค่ห้า

นี่คือจุดที่ Mokbi เข้ามาพอดี และคุ้มค่าที่จะพูดชัดเจนเรื่องขอบเขต Mokbi ไม่ ถ่ายภาพแอปของคุณ — คุณยังต้องผลิต source frame ด้วย command Expo ข้างต้น สิ่งที่มันทำคือรับ frame เหล่านั้นและให้คุณทำใน browser: วางลงในกรอบอุปกรณ์จริง เพิ่มคำบรรยายและพื้นหลัง gradient จัดวางคารูเซลหลายพาเนล one-click แปลคำบรรยายเป็น 50 ภาษา และ batch export ทุกขนาด App Store และ Play Store ในครั้งเดียว ออกแบบฟรีพร้อม watermark ตัวอย่าง; ส่งออกแบบไม่จำกัดมาพร้อมกับการสมัครสมาชิก — Solo €29.99/mo (1 แอป) หรือ Studio €49.99/mo (สูงสุด 5 แอป) ไม่มีการซื้อแบบครั้งเดียว มันแทนที่ขั้นตอน Figma template ที่คำแนะนำของ Expo พาดพิงถึง — ไม่มากไม่น้อย

เวิร์กโฟลว์ผสมผสานที่เป็นจริง

1. Build dev/preview client. npx expo run:ios และ npx expo run:android ใส่ demo data ที่ดี
2. ถ่าย source frame. แบบ manual ผ่าน xcrun simctl io booted screenshot และ adb exec-out screencap -p หรืออัตโนมัติผ่าน Maestro takeScreenshot / Detox device.takeScreenshot — ดีที่สุดบน EAS Workflows เพื่อให้สร้างใหม่ทุก release
3. จัดวางพาเนลทางการตลาด. ห่อกรอบ เพิ่มคำบรรยาย และจัดเรียงคารูเซลจาก frame แบบ raw เหล่านั้น
4. แปลภาษาและ batch export. แปลคำบรรยายข้ามภาษาเป้าหมาย ส่งออกทุกขนาดที่กำหนดสำหรับทั้งสอง store
5. อัปโหลด listing assets. ภาพหน้าจอไปที่ App Store Connect และ Play Console; คู่กับ EAS Metadata สำหรับ text field ถ้าใช้
6. Submit binary. eas submit — ขั้นตอนเดียวที่ EAS เป็นเจ้าของจริงๆ
7. Release ถัดไป: ถ่ายหน้าจอที่เปลี่ยนแปลงใหม่ เปิดโปรเจกต์จัดวางที่บันทึกไว้ เปลี่ยน frame ส่งออกใหม่ คำบรรยายและการแปลยังอยู่ครบ

เมื่อไหร่ที่ข้าม automation ได้

ใช้ Maestro หรือ Detox ถ่ายภาพเมื่อ screenshot drift เป็นต้นทุนจริง: ส่งงานทุกสัปดาห์ UI เปลี่ยนตลอด หรือดูแลหลายแอปและไม่สามารถปล่อยให้ store image ล้าสมัยได้ ในกรณีเหล่านั้น frame ที่สร้างใหม่จาก CI คุ้มค่าการลงทุน และ เรื่องราว screenshot tooling ของ React Native (ซึ่ง Expo สืบทอดมา) คุ้มค่าลงทุน

สำหรับคนอื่นทุกคน — ผู้ส่งงานไตรมาสละครั้ง — ข้ามไปได้เลย การถ่ายแบบ manual ด้วยสอง terminal command จากนั้นจัดวางและแปลภาษาบน browser พาคุณไปถึง listing หลายภาษาที่ขัดเกลาแล้วภายในบ่ายวันเดียวโดยไม่มีอะไรต้อง maintain ระหว่าง release จับคู่เครื่องมือให้ตรงกับจังหวะของคุณ ไม่ใช่สิ่งที่ดูน่าประทับใจบน CI dashboard

ไม่ว่าจะเลือกทางไหน ส่วน binary แก้แล้ว: eas submit จัดการ ตรวจสอบภาพหน้าจอให้ตรงกับ ข้อกำหนด store ปัจจุบัน ก่อนอัปโหลด — Apple ปฏิเสธ listing เพราะพิกเซลคลาดเคลื่อนเพียงหนึ่งพิกเซล — แล้วส่วนที่เหลือของ launch ก็เป็นแค่เรื่องออกแบบ

อ่านต่อ

• สำหรับนักพัฒนา Expo
• ภาพหน้าจอ App Store สำหรับ React Native
• Side-by-side: Mokbi vs Fastlane
• ขนาดภาพหน้าจอ App Store
• ข้อกำหนดภาพหน้าจอ App Store

เปิดเครื่องมือแก้ไข →