Expo App Store 截图：为什么 EAS Submit 不处理截图，以及如何快速搞定（2026）
.ipa/.aab 上传到 App Store Connect 和 Play Console——仅此而已。它不会生成、上传或管理商店截图。因此 Expo 开发者需要单独的截图流程：从开发/预览构建中捕获原始帧（模拟器、模拟器或 Maestro/Detox），再将其组合并本地化为营销面板。本文如实介绍捕获命令，以及组合工具所处的位置——它不替你捕获任何内容。如果你发布过 Expo 应用，发版路径大概以一行命令结尾：eas submit。它把 EAS 构建好的包交给 Apple 或 Google，干净、简单、可靠。然后你打开 App Store Connect 准备让构建上线——截图栏位却是空的。每次都是。
这让很多人感到困惑，因为 EAS 看起来什么都能做。构建、签名、提交，截图肯定也在里面？并不是，文档说得很清楚。这不是 bug，也不是可以提需求的缺失功能——它就是不在 EAS Submit 的职责范围内。
EAS Submit 实际做什么（以及不做什么）
EAS Submit 是一个二进制交付服务。它只上传一件东西：你编译好的应用包——iOS 对应 .ipa，Android 对应 .aab——进入商店的处理流水线。Expo 文档对这个边界有明确说明：
"EAS Submit 上传你的二进制文件，但不管理商店列表元数据、截图或发版说明。"
有一个配套工具 EAS Metadata，它可以通过配置文件自动化 App Store 列表的部分内容——应用名称、副标题、本地化描述、关键词、支持 URL。这个工具确实有用，值得配置。但要仔细看清它的范围：截图不在其中。EAS Metadata 推送的是文本，不是图片。两个商店的截图，仍然需要你自己制作和上传。
所以 Expo 的截图问题分为两项独立的工作，在脑子里把它们区分开会很有帮助：
- 捕获——从构建中获取应用真实界面的原始帧。
- 组合与本地化——将原始帧转化为商店实际展示的带框、带文案、多语言营销面板。
EAS 两项都不做。Expo 自己的商店素材指引建议你自行捕获帧，然后用 Figma 等工具设计面板。下面用具体命令逐一说明这两项工作。
工作一：从开发或预览构建中捕获帧
你需要真实应用的截图，因此需要在某个可以捕获的地方运行应用。对 Expo 而言，这意味着开发客户端或预览构建——而非 Expo Go，因为 Expo Go 显示的是 Expo 自身的包装 UI，且你的原生配置可能有所不同。用标准 Expo 命令在本地构建并运行：
npx expo run:ios——预构建原生 iOS 项目，编译并在 iOS 模拟器中启动应用。npx expo run:android——对 Android 模拟器（或连接的设备）执行相同操作。
应用在 iOS 模拟器中显示后，在 Mac 终端执行一条命令即可完成捕获：
xcrun simctl io booted screenshot home.png
booted 指向当前运行的模拟器，并将像素精确的 PNG 写入你的工作目录。对商店素材有影响的两个参数：--type=png（默认值，也是商店所需的格式）以及 --mask=ignored 与 --mask=black 的区别——mask 控制刘海和圆角是否渲染到图像中。上传 App Store 时通常需要平整的矩形像素，之后再在组合阶段添加设备框架，所以不带 mask 的捕获通常是正确的起点。
在 Android 上，直接用 adb 从模拟器（或设备）捕获：
adb exec-out screencap -p > home.png
要用 exec-out，而非 shell screencap。普通 shell 路径会把 PNG 经由伪终端传输，在某些环境下会损坏二进制文件（因为混入了多余的回车符，导致文件损坏）；exec-out 直接流式传输字节，是可靠的方式。如果同时运行多个模拟器，用 adb devices 获取序列号后通过 adb -s <serial> 指定目标。
这就是完整的手动捕获工具箱：两条命令，每平台一条，除了你做 Expo 原生构建时已有的 Xcode 和 Android SDK 外，没有额外依赖。
工作一，自动化版：Maestro 或 Detox
手动导航到目标界面再执行命令，对几张截图来说没问题。一旦你需要覆盖两种设备类型共八个界面，或者希望每次发版都重新生成截图以避免与真实 UI 产生偏差，就需要用端到端测试工具来自动化捕获——它既能驱动应用，也能截图。
Maestro 是 Expo 在其文档化 EAS Workflows 示例中采用的工具。流程用纯 YAML 编写，门槛很低。一个驱动到某界面并截图的流程如下所示：
appId: com.you.yourapp --- - launchApp - tapOn: "Get started" - assertVisible: "Your dashboard" - takeScreenshot: dashboard
用 maestro test flows/home.yaml 运行。takeScreenshot 命令将 PNG 写入测试输出目录（通过 MAESTRO_TESTS_DIR 指定素材保存位置）。同样的流程可以在 EAS Workflows 的 CI 上运行——Expo 的文档示例是用 e2e-test 构建配置构建 .apk，然后对其运行 .maestro/ 流程——因此你可以把截图捕获接入与 e2e 测试同一个 job。
Detox 是另一个成熟选项，拥有更严谨、更程序化的 JavaScript API：
const path = await device.takeScreenshot('dashboard');
不过要对 Detox 与 Expo 的集成保持清醒认识。Detox 不官方支持 Expo。实际上，你需要先 npx expo prebuild 生成原生项目，再构建一个类发布版客户端（而非开发客户端）让 JS bundle 内嵌——然后将 Detox 指向该二进制文件。这比 Maestro 的 YAML 方式多了更多环节，换来的是 Detox 更严格的同步和断言 API。如果你已经在用 Detox，复用它来捕获截图是合理的；如果你是从头选型且目标是商店截图，Maestro 是更轻量的路径。
工作一，手动版：低频发版的合理选择
自动化在频繁发版时才值回成本。如果你一年发一到三个版本——大多数独立 Expo 应用都是这种节奏——配置 Maestro 流程或 Detox 截图配置是只用一次却几乎没有摊销的投入。对于这种节奏，只需：
- 启动构建，用
npx expo run:ios/run:android，填入真实的演示数据。 - 手动导航到每个核心界面。
- 用上面的
simctl/adb命令逐一截图。
二十分钟的点击操作，胜过半天都记不住怎么维护的测试框架。手动截图没什么丢人的——商店根本不关心 PNG 是怎么生成的。
工作二：组合与 50 语言本地化
这部分是截图工具刻意不涉及的，也是商店真正用来衡量你的部分。一张原始的 simctl PNG 只是白底上的应用 UI。在搜索中排名靠前、在产品页面带来转化的，是营销面板：放在设备框架内的截图，搭配品牌背景，加上一行说明这个界面价值的文案——通常以从左到右阅读的多面板轮播图呈现。在 App Store 上，截图还要按设备尺寸和语言分别本地化，所以认真发版意味着几十个变体，而不是五张。
这正是 Mokbi 所处的有限边界，值得说清楚。Mokbi 不捕获你的应用——你仍然需要用上面的 Expo 命令生成源帧。它做的是：接收这些帧，让你在浏览器中将它们放入真实设备框架、添加文案和渐变背景、排布多面板轮播图，一键将文案翻译为 50 种语言，并一次性批量导出所有 App Store 和 Play Store 尺寸。设计阶段免费（带水印预览）；无限量无水印导出需订阅——Solo €29.99/mo（1 个应用）或 Studio €49.99/mo（最多 5 个应用），不再提供一次性买断。它替代的是 Expo 指南一笔带过的 Figma 模板步骤——不多不少。
现实可行的完整工作流
- 构建开发/预览客户端。
npx expo run:ios和npx expo run:android，填入真实演示数据。 - 捕获源帧。手动用
xcrun simctl io booted screenshot和adb exec-out screencap -p，或通过 MaestrotakeScreenshot/ Detoxdevice.takeScreenshot自动化——最好接入 EAS Workflows，每次发版自动重新生成。 - 组合营销面板。从原始帧出发，添加设备框架、文案，排布轮播图。
- 本地化并批量导出。将文案翻译为目标语言，按两个商店的所有必需尺寸批量导出。
- 上传商店素材。将截图上传到 App Store Connect 和 Play Console；如有需要，配合 EAS Metadata 同步文字字段。
- 提交二进制文件。
eas submit——这是 EAS 真正负责的唯一步骤。 - 下次发版时：重新捕获变更的界面，重新打开保存的组合项目，替换帧，重新导出。文案和翻译已经完成，无需重做。
什么时候可以跳过自动化
当截图脱节是真实成本时，才需要 Maestro 或 Detox 捕获：你每周发版、UI 频繁变更，或者维护多款应用且无法接受过期的商店截图。在这些情况下，CI 自动重新生成截图才值得投入，React Native 截图工具链（Expo 也继承了这套体系）才是值得的选择。
对其他人——每季度发一次版的开发者——跳过自动化就好。两条终端命令手动捕获，再加浏览器端组合与本地化，一个下午就能搞定精良的多语言商店列表，两次发版之间什么都不需要维护。让工具匹配你的节奏，而不是让 CI 看板好看。
不管哪种方式，二进制那半边已经解决：eas submit 搞定。上传前记得对照当前商店要求检查截图——Apple 会因为一个像素的偏差拒绝提交——剩下的就只是设计的事了。