App Store 截图尺寸 2026：多语言素材准备与上传教程

返工通常不是从导出环节开始，而是从“没有人明确哪些素材必须存在”开始。发布负责人应先把应用支持的平台、设备类别、目标语言、首发市场和版本状态写进一张表。

矩阵至少要包含以下字段：

Apple 当前截图规则允许每个本地化位置上传 1—10 张截图。截图支持 .jpeg、.jpg 和 .png，但不能包含 Alpha 通道或透明效果。(developer.apple.com)

如果你的应用同时支持 iPhone 和 iPad，不要把两者当作同一套素材。iPhone 6.9 英寸显示类别的官方截图尺寸包括 1260 × 2736、1290 × 2796、1320 × 2868 像素等竖屏规格；iPad 13 英寸显示类别则包括 2064 × 2752 或 2048 × 2732 像素等规格。具体采用哪一组，要以 Apple 当前 Screenshot Specifications 页面列出的设备类别为准。

发布负责人还要确认版本是否处于可编辑状态。处于 Ready for Review、Waiting for Review 或 In Review 等阶段时，截图和 App Preview 的修改权限不同；尤其是提交后等待审核期间，不能继续上传或编辑截图和视频。(developer.apple.com)

设计环节不要从论坛下载“最新 iPhone 模板”。2026 年的官方规格已经包含新的设备分类，历史模板可能在像素、比例或状态栏处理上不再适用。

建议按以下顺序制作：

1. 从 Apple 官方 Screenshot Specifications 页面确认平台和设备类别。
2. 为每个平台选择一组最高分辨率主素材。
3. 在设计文件中单独保留界面截图层、设备外框层、营销文案层和背景层。
4. 将截图中的界面语言与目标商店语言对应起来。
5. 导出后检查像素、方向、文件格式和透明通道。
6. 把可编辑源文件、导出文件和语言文案放入同一版本目录。

如果多个设备尺寸上的界面完全一致，可以先上传最高分辨率截图，让 App Store Connect 自动缩放到较小尺寸。Apple 同时允许你通过 Media Manager 为其他设备尺寸上传自定义截图。(developer.apple.com)

但“自动缩放”只解决尺寸适配，不会替你解决内容问题。以下情况不应直接复用：

• 小屏幕上标题会被裁切，或营销文案无法阅读。
• 平板界面增加了侧栏、双栏或额外功能。
• 某个市场的支付方式、配送方式或核心功能不同。
• 目标语言的词长明显增加，导致按钮和说明文字换行。
• 截图展示了只在部分地区开放的功能。

每张图都要进行一次真实性检查。截图里的功能必须在当前版本中可用，价格、货币、配送承诺、会员权益和市场卖点也不能与产品页其它元数据矛盾。设计负责人不要只交 PNG；下个版本需要复用时，没有源文件就会重新搭建整套画面。

不同语言可以共用同一组截图，但判断标准不是“图片上有没有大段文字”，而是画面是否仍然准确表达目标市场的产品体验。

可以复用的典型条件：

• 应用界面本身没有显示语言差异。
• 截图只展示图标、图表或不含文字的操作结果。
• 功能范围、价格逻辑和市场卖点完全一致。
• 图片中的品牌词在目标语言中不需要改写。

必须重新制作的典型条件：

• 截图标题、按钮或功能说明已经本地化。
• 某市场的功能、支付、配送或内容库不同。
• 目标市场需要强调不同的使用场景。
• 原图的文字在另一种语言中会出现截断或层级变化。

App Store Connect 中，新增语言时，截图和多数属性会先继承主语言内容，但描述和关键词不按同样方式处理。若用户语言没有对应本地化，系统会使用下一个相关语言；在其它地区，则可能回退到主语言。(developer.apple.com)

所以，本地化负责人必须维护三方核对记录：

• 应用界面：截图中的功能名称、按钮和页面路径是否真实。
• 图片文案：标题、卖点、数字和行动指引是否符合当地表达。
• 商店元数据：应用名称、副标题、描述和关键词是否讲同一套卖点。

不要把图片标题机械翻译后直接覆盖。App Store 截图首先是转化素材，其次才是翻译文件。你需要重新检查信息层级：第一张图是否仍然表达最重要的价值，第二张图是否展示关键功能，后续图片是否能解释使用结果。

上传时，管理员需要同时核对“语言”和“设备”。这两个选择器一旦错位，文件可能上传成功，却出现在错误的本地化位置。

按下面的流程操作：

1. 登录 App Store Connect，进入目标 App。
2. 在侧边栏打开需要提交的平台版本。
3. 选择 iPhone、iPad 或其它目标平台。
4. 在 App Previews and Screenshots 区域上传默认素材。
5. 切换到目标语言，确认当前页面显示的是正确本地化。
6. 点击 View All Sizes in Media Manager。
7. 进入对应设备标签，选择需要自定义的设备尺寸。
8. 将文件拖到正确素材槽位。
9. 检查处理状态、缩放结果和首屏排序。
10. 截取脱敏后台记录，交给地区验收人员。

Apple 指定的上传入口允许你在平台版本页面直接拖入截图和 App Preview；如果要补充其它设备尺寸或本地化素材，则需要在 Media Manager 中选择语言、设备标签和对应编辑区域。

上传后不要只看“文件已出现”。至少检查四项：

• 图片是否被平台缩放，文字边缘是否变糊。
• 第一张截图是否仍然是最重要的卖点。
• App Preview 是否出现在截图之前。
• 当前版本是否仍允许编辑素材。

App Preview 是可选视频，不是所有应用都必须制作。Apple 当前规格要求视频时长为 15—30 秒，文件大小不超过 500 MB，支持 H.264 或 ProRes 422（仅 HQ），常见扩展名为 .mov、.m4v 和 .mp4。(developer.apple.com) 每个语言、设备尺寸最多可提供 3 个 App Preview。

制作和上传 App Preview 按 Apple 当前要求需要 macOS 10.10 或更高版本，以及 Safari 8 或更高版本。macOS、tvOS 和 visionOS 的 App Preview 只能使用横向方向；iOS App Preview 可以使用横向或竖向。(developer.apple.com)

这也是远程 Mac 真正有价值的场景：设计人员可以在 Mac 上完成视频编辑，上传管理员继续使用同一环境检查素材，项目负责人再通过远程会话完成交接。它不能绕过 App Store 地区规则，也不能保证审核通过或某个地区一定展示指定素材。

后台上传成功不等于验收完成。地区验收人员需要在目标语言和目标市场下检查实际展示结果，特别是首屏素材、回退语言和 App Preview 顺序。

建议保存两类证据：

1. 搜索结果证据：记录用户可能首先看到的前部素材、应用名称和副标题。
2. 完整产品页证据：检查全部截图、视频、语言、文案和功能卖点。

App Preview 在产品页上会排在截图之前，即使你在编辑页面中重新排列，也不能把它放到截图之后。若某个店面的本地化没有单独 App Preview，系统可能使用下一个最匹配语言的 App Preview。(developer.apple.com)

验收时重点看以下问题：

• 首屏是否意外显示主语言，而不是目标语言。
• 图片中的界面语言是否与标题和描述一致。
• 关键按钮、价格和功能是否被裁切。
• 不同语言的截图顺序是否仍符合当地卖点。
• 视频封面是否能代表实际功能，而不是停在加载页或空白页。

如果团队分处不同地点，可以使用远程 Mac 保持独立的浏览器语言、账号和验收会话。这样做的价值是减少本地环境混用，方便把上传、检查和交接记录放在同一台持续在线的 Mac 上；它不是地区限制绕过方案，也不能替代真实的 App Store 验收。

在需要跨市场核对搜索结果时，可以先参考 App Store 多语言元数据本地化流程 相关内容，再把截图文案与商店名称、副标题、关键词逐项比对。若同一团队还维护多个开发者主体，素材验收与账号权限也应分离记录，避免把错误素材上传到另一款 App。

提交前，项目负责人要把素材交付从“设计完成”变成可追溯的版本记录。建议每个版本至少保存以下文件：

• 平台与设备素材矩阵。
• 各语言文案最终稿。
• 可编辑设计源文件。
• 已上传导出文件。
• 上传人员和上传时间记录。
• Media Manager 处理状态截图。
• 目标地区产品页验收截图。
• 未通过项、修复人和复验结果。

单人团队可以按下面的顺序执行：

• ✅ 先确认平台、语言和版本状态。
• ✅ 再核对官方尺寸、格式和方向。
• ✅ 逐张检查图片文字与当前版本界面。
• ✅ 上传后检查缩放、排序和处理状态。
• ✅ 最后用目标语言验收实际产品页。

多人团队则需要额外增加责任边界：

• ✅ 发布负责人维护矩阵，不让设计人员自行猜测交付范围。
• ✅ 设计负责人只对像素、画面真实性和源文件负责。
• ✅ 本地化负责人确认语言表达、功能范围和市场卖点。
• ✅ 上传管理员确认平台、设备、语言和状态。
• ✅ 地区验收人员只提交产品页问题，不直接覆盖源文件。
• ✅ 项目负责人保留最终版本和变更记录。

如果截图已随版本提交并进入审核，修改空间会受到状态限制；通过审核后，部分截图更新需要创建新版本。Apple 的可编辑属性表和状态说明应作为交接依据，不要用团队内部旧流程替代平台当前规则。(developer.apple.com)

如果你只处理几张静态 PNG，专门准备 Mac 往往没有必要；如果你需要制作 App Preview、持续上传、多人交接，或者团队成员没有一台长期可用的 Mac，短周期远程环境更容易控制交付边界。你可以先了解 美国节点 Mac 环境，再根据发布周期决定是否需要远程 Mac。

Windows 或 Linux 可以完成文案整理、设计协作和文件检查，但它们不能替代 Apple 当前要求的 macOS 与 Safari App Preview 工作环境。自购 Mac 适合长期、高频、需要本地物理接口的团队；临时项目、跨地域协作和版本集中发布，则更适合按周期使用远程 Mac。

这类方案仍有三个现实限制：远程画面受网络质量影响，视频编辑体验取决于会话稳定性，团队还必须自行管理账号权限和文件留档。因此，租用 CALMVPS 的远程 Mac 时，应把重点放在交付检查、管理员权限、素材传输和验收记录，而不是把它当作审核加速或上架保证。

最终判断很简单：静态截图少、更新低频，就按官方规格本地制作；需要 App Preview、连续上传和多人维护，又没有持续可用的 Mac，就先用短周期远程 Mac 完成交付。项目团队应根据发布周期、素材类型和协作人数决定是否租用，而不是为了一个图片尺寸问题长期购买硬件。