我的第一次 Mac App 上架被拒日记

第一次向 Mac App Store 提交应用，我原本以为这是一件「走流程」的事情。

功能已经做完，逻辑跑通，界面也算克制耐看——在我看来，已经具备了一个“可以交付”的状态。

但当真正进入 App Review 阶段，我才意识到：写代码只是开发的一部分，而审核，是另一套完全不同的规则体系。

这篇文章记录我在同一个版本中，连续两次被拒的经历，以及这两次拒绝背后，真正需要注意的点。

第一次被拒：2.1.0 App Completeness —— 内购不是“以后再说”的事情

第一次提交后没多久，我收到了 Rejected 通知：

Guideline 2.1.0 – Performance – App Completeness App 中包含 Pro / Lifetime 等内购相关引用，但对应的 In-App Purchase 并未提交审核。

这其实是一个非常典型、也非常容易被忽略的情况。

当时我的想法是：

• App 里先把 Pro / 终身版的入口放好
• 功能逻辑先实现
• 内购等后面再慢慢补

但 Apple 的态度非常明确：

只要 App 里出现了“付费相关的引用”，就必须存在一个已经提交审核的 In-App Purchase。

哪怕只是一个按钮、一行文案，或者一个尚未开放的功能入口，都不例外。

这次拒绝真正暴露的问题

回头看，这次被拒并不是因为“内购没写完”，而是我对 IAP 在审核流程中的地位 理解不足。

几个关键点：

1. IAP 是产品的一部分，不是附加功能 写了 Pro，就要为它负责

2. 第一次内购有额外规则 首次 IAP 不能单独提交，必须和一个新的 App Build 一起送审

3. Missing Metadata 会直接卡死流程 描述、价格、本地化、审核截图，缺一不可

第一次被拒后的经验

• 不要在 App 中“提前画饼”
• 内购不是占位符，而是正式功能
• 第一次 IAP：新 Build + 版本页关联 + 一起提交

第二次被拒：不是功能问题，而是合规与信息问题

在补齐内购信息、重新上传 Build 后，我一度以为这次应该可以顺利进入审核。

但结果并没有。

第二次被拒涉及两个点：一个是 Entitlement 权限问题，另一个是 Support URL。

2.4.5(i)：多余的 Entitlement，同样会被点名

Apple 指出我的 App 使用了以下权限：

com.apple.security.network.server

但在应用中，并未看到与之对应的功能。

这个 entitlement 的含义是：

• 在本地监听端口
• 作为网络服务器
• 接收外部网络连接

而实际情况是，我的 App 只是进行普通的网络请求，并不存在本地 server 行为。

换句话说，这个权限 并非必要。

这一点带来的反思

Apple 对 macOS App 的一个核心要求是：

只使用“最小且必要”的权限集合。

哪怕功能完全正常，只要权限和功能之间的对应关系说不清楚，就会被拦下来。

好在这是一个「解释型问题」，只需要在 Review 回复中明确说明：

• 该权限并未被使用
• 会在后续版本中移除

即可继续审核，而不需要立刻上传新版本。

Guideline 1.5：Support URL 不是摆设

第二个问题看似很小，但非常容易被忽略。

Apple 指出：

当前提供的 Support URL，未指向一个可以让用户请求支持的页面。

我的 Support URL 实际上只是一个产品展示页，并没有提供：

• 联系方式
• 支持说明
• 问题反馈入口

但 Apple 的要求其实非常朴素：

用户点进去，应该知道“如何联系到开发者”。

哪怕只是一个邮箱地址，或者一个简单的 Contact 页面，也足够。

写在最后：给未来自己的审核备忘

经历这两次被拒之后，我给自己总结了几条非常具体的提醒：

1. App Review 是产品交付的一部分，而不是上线前的例行公事
2. 只要出现付费相关文案，就必须有 IAP 在审
3. 第一次 IAP，必须配合新 Build 一起提交
4. Entitlement 必须能清楚解释，否则宁可删除
5. Support URL 必须真的能让用户联系到你

回头看，这两次拒绝并不算糟糕。

它们更像是在提醒我：

一个“能用的 App”，和一个“可以被上架的 App”，中间还有一段需要认真对待的距离。

如果你也正在准备第一次提交 Mac App，希望这份记录能帮你少踩一些坑。