夜雨聆风如果你也刚做完一个 macOS 软件，准备第一次上架 App Store，大概率会和我一开始一样：
•
不知道先做什么，后做什么
•
不确定 App Store Connect 里哪些字段必须填
•
不知道截图、隐私、审核备注到底该怎么准备
•
更担心提审之后被 Apple 一顿打回
这篇文章我尽量站在一个“小白开发者”的视角，把我这次把 DailyEnglish 提交到 Mac App Store 审核的完整过程讲清楚。
这不是一篇只讲理论的说明文，而是一篇带着真实项目落地过一遍的复盘。你可以把它理解成：
一个第一次上架 macOS App 的人，如何从“完全没经验”走到“已经提交等待审核”。
上图就是这次最终的状态：已提交 1 个项目，进入等待审核。
先说结论：macOS App 上架，核心不是“点按钮”，而是“先把产品边界收干净”
很多人以为上架流程的难点在 Xcode 打包、上传构建、填 App Store Connect。
但我这次最大的体感是：
真正决定你能不能顺利提审的，不是最后那几个按钮，而是你有没有提前想清楚这几个问题：
1.
你的首版到底卖什么
2.
你的 App 是否存在会被 Apple 追问的账号、支付、会员、权限、隐私问题
3.
你的产品页文案、截图、审核备注，是否和 App 里的真实体验一致
只要这三件事理顺，后面的工作虽然繁琐，但并不神秘。
我的项目背景
这次提交的是 DailyEnglish 的 macOS 端。
我最初的整体产品其实有三个端：
•
Chrome 插件端
•
macOS 桌面端
•
Web 端
但在真正准备 App Store 首发时，我没有把三端能力一股脑全部塞进 Mac 版本，而是做了一个非常重要的收敛：
首版只把它当成一个“菜单栏英语翻译工具”来提交。
我保留的核心能力只有这几项：
•
输入翻译
•
划词翻译
•
截图翻译
•
OCR 识别
•
本地翻译历史
•
菜单栏常驻入口
这个决定非常关键，因为它直接影响后面所有的审核风险。
第一步：先决定“首版怎么卖”，再决定“功能怎么收”
一开始我其实有不少复杂设想，比如账号体系、跨端同步、会员权益之类。
但越往后看越发现，首版如果想顺利过审，越简单越好。
所以我最后采取的是这条路线：
•
Mac App Store 买断版
•
用户通过 App Store 一次性付费下载
•
不要求额外注册账号
•
不暴露登录、注册、会员、跨平台权益等入口
这一步背后的思路很朴素：
如果首版一上来就带上登录、外部购买、会员体系、跨端同步，Apple 审核很容易继续追问：
•
为什么不用 Sign in with Apple
•
为什么没有 App 内账户删除
•
为什么会员能力不走 App 内购买
•
为什么下载后还要去外部注册
所以我最后做的不是“把所有功能都搬上来”，而是“先做一个审核路径最清晰的版本”。
第二步：先改产品，再谈提审
在进入 App Store Connect 之前，我先把本地产品做了一轮“App Store 化”处理。
我主要做了这些收口：
•
隐藏登录、账户、同步相关入口
•
把“我的翻译”改成了本地历史记录
•
关于页改成买断版文案
•
保留输入翻译、划词翻译、截图翻译这几个最清晰的功能点
做完这一步，产品表达就变得非常统一：
它不是一个复杂的跨端英语学习平台，而是一个菜单栏翻译工具。
这个统一性非常重要，因为产品页、截图、隐私声明、审核备注，最终都要围绕同一个故事来写。
第三步：准备 App Store 所需资料
真正开始填 Apple 后台时，我发现需要准备的资料远比想象中多。
至少要提前想清楚下面这些东西：
•
App 名称
•
副标题
•
推广文本
•
描述
•
关键词
•
Support URL
•
Marketing URL
•
Privacy Policy URL
•
审核联系人
•
审核备注
•
截图
•
隐私披露
•
定价
如果这些内容不提前整理，等你打开 App Store Connect 再现场写，会非常痛苦。
我这次的做法是先在本地写一份草稿，把所有字段一次性整理好，再往后台填。
第四步：截图一定要提前准备，而且要按 Apple 规格来
很多第一次上架的人，都会低估截图这件事。
但实际上，截图不是可有可无的装饰，它既影响提审效率，也影响用户第一眼的理解。
Mac App Store 对截图尺寸是有要求的，这次我准备的是 2560 x 1600 的 16:10 成品图。
我最后用了 6 张图就完成了首版提交：
•
输入翻译主界面
•
本地翻译历史
•
快捷键和语言设置
•
权限与通用设置
•
翻译服务配置
•
关于页与支持入口
1. 主界面截图
这类图最重要的不是“看起来炫”，而是让用户一眼知道：
这个 App 到底是干什么的。
2. 权限与设置截图
因为我的 App 有 Accessibility 和 Screen Recording 相关功能，所以我专门把权限和设置做进了截图素材里。
这样 Apple 审核和用户都会更容易理解：
•
权限是用户主动开启的
•
没有权限时，App 也不是完全不可用
3. 关于页与支持入口截图
这类截图的价值在于增强“这是一个完整产品”的感觉。
尤其对于首版 App 来说，支持链接、隐私政策入口、版本信息，都会让整个产品页更完整。
第五步：App 权限一定要解释清楚
我的 App 有两个很敏感、但其实也很常见的权限：
•
Accessibility
•
Screen Recording
它们分别对应：
•
划词翻译
•
截图翻译
这类权限本身不是不能用，问题在于你必须说清楚：
1.
用户为什么要开这个权限
2.
这个权限是在什么场景下使用
3.
如果用户不开，会发生什么
我这次在审核备注里讲得非常直接：
•
Accessibility 只在用户主动触发划词翻译时使用
•
Screen Recording 只在用户主动发起截图翻译时使用
•
如果用户不授予权限，手动输入翻译仍然可以正常使用
这类表述的好处是，Apple 很容易判断你不是在后台偷偷采集信息，而是在明确的交互路径里使用系统能力。
第六步：App 隐私别乱填，先按“真实数据流”拆解
我一开始也很怕 App Privacy，总觉得这里很容易填错。
后来我发现一个简单办法：
不要从“我想怎么填”出发，而要从“用户的数据到底流向了哪里”出发。
比如我的场景里，用户会输入文本、划词、截图识别文字，然后把这些内容交给翻译能力去处理。
那从数据类型上看，最需要披露的就是：
•
Other User Content
用途是：
•
App Functionality
是否追踪：
•
No
这个页面最怕两种情况：
•
明明会上传用户文本，却写成“没有收集数据”
•
明明有账号和日志关联，却没有补充相关披露
所以建议大家一定先把自己的真实数据流过一遍，再去填隐私页。
第七步：定价不是你想填多少就能填多少
这个点我觉得很多第一次上架的人也会忽略。
我原本想把首版价格定成 19 元，但真正进入 App Store Connect 之后才发现，Apple 采用的是价档体系，不是让你随便输入一个数字。
最后我选的是最接近的档位：
•
中国大陆 (CNY) ¥18.00
所以如果你对价格特别敏感，建议早点去看 Apple 的价格档位，不要等到最后才发现没有你想象中的那个整数。
第八步：审核备注非常重要，别只写一句“please review”
如果你的 App 很简单，审核员点开就能懂，那备注可以短一点。
但如果你的 App 有以下任意一种情况，审核备注就一定要认真写：
•
菜单栏应用
•
首次打开没有传统主窗口
•
需要特殊权限
•
某些功能需要特定触发方式
•
不登录也能用，但部分能力有条件
我的 App 就属于典型的“菜单栏工具类”产品，所以备注里我专门写了：
1.
App 启动后不会自动弹一个传统主窗口
2.
审核员应该去点菜单栏图标
3.
手动输入翻译可以直接体验
4.
划词翻译和截图翻译需要在授权后测试
5.
未授权时仍可以使用手动输入翻译
这样审核员就不至于一脸懵地打开 App，然后因为没找到入口就给你一个“功能不可用”。
第九步：真正提审前，最好做一次“全链路检查”
我建议在点“提交审核”之前，至少过一遍下面这个检查清单：
•
App 的版本号、构建号是否一致
•
App Store Connect 中的版本信息是否和本地版本匹配
•
截图是否符合尺寸要求
•
产品页文案是否和 App 内实际功能一致
•
Support URL 是否能正常打开
•
Privacy Policy URL 是否可访问
•
权限描述和审核备注是否一致
•
定价是否已经真正保存
•
提审的 build 是否是最新版本
这些事情看起来都不复杂，但只要漏一个，你就可能来回折腾很多轮。
第十步：第一次上架，最容易踩的坑是什么
如果让我复盘这次经历，我觉得最容易踩的坑主要有 6 个：
1. 一上来就想提一个“功能最全”的版本
这通常会把审核复杂度直接拉满。
首版更好的策略往往是：
功能少一点，但边界清楚一点。
2. 产品页写得很大，App 里却没有完全体现
比如你明明只是一个翻译工具，却在文案里写成完整学习平台，那审核员和用户都会产生落差。
3. 没把权限用途说清楚
特别是 Accessibility、Screen Recording 这类权限，最好在截图、设置页、审核备注里形成统一解释。
4. 低估截图准备成本
Mac App Store 的截图不是随手一截就行，尺寸、比例、页面状态、文案表达都要提前设计。
5. 以为隐私页只是“形式化填写”
其实这里和你的实际数据处理逻辑是强相关的，填错了风险不小。
6. 最后一步才去想价格、支持页和隐私政策
这些看起来像“运营资料”，但实际上都是提审必需品。
我这次最深的感受
如果让我用一句话总结这次 macOS App 上架经历，我会说：
上架 App Store，本质上是在把一个“能跑的程序”整理成一个“可以被平台理解、被用户购买、被审核通过的产品”。
你会发现，真正的工作不只是写代码，还包括：
•
做取舍
•
明确首版范围
•
梳理权限和隐私
•
写清楚产品文案
•
把审核路径设计出来
这些事情做完之后，点击“提交审核”反而只是最后一个很小的动作。
最后，给第一次上架 macOS App 的朋友一个建议
如果你现在也准备第一次发 macOS App，不妨按下面这个顺序来：
1.
先确定首版卖点，不要一开始就贪大求全
2.
先把 App 内容易引发审核问题的内容收干净
3.
提前准备文案、截图、隐私政策、支持页
4.
在 App Store Connect 里逐页核对，而不是凭感觉“应该已经填了”
5.
提交前做一次完整复查
你不需要一开始就对 Apple 审核机制非常熟。
但你确实需要把自己的产品边界讲清楚。
当你做到这一步，macOS App 上架这件事就不会再是“完全无从下手”，而会变成一套可以拆解、可以执行的流程。
附：这次首版提交的产品定位
为了方便你参考，我把这次 DailyEnglish 提交时的首版定位也放在最后：
•
产品形态：macOS 菜单栏翻译工具
•
核心功能：输入翻译、划词翻译、截图翻译、OCR、本地历史
•
付费方式：Mac App Store 买断
•
审核策略：不要求登录，不暴露会员、同步、外部购买路径
•
权限重点：Accessibility 与 Screen Recording
•
当前状态：已提交审核，等待结果
