这个 App Store 审核 Skill,适合放在发版前一天用

这是codedoctor的第 62 篇原创

01 发版前夜最需要它

—

凌晨一点，iOS 同学最怕的通常不是代码还没写完。

最怕的是包已经打好，脑子里忽然冒出一句：这次会不会又被拒？

这句话很烦，因为它不指向某一行代码。

它可能是一个权限描述少写了。

也可能是三方登录用了 Google，却忘了 Sign in with Apple。

还有可能是订阅页没有 Restore Purchases，或者 App 里有注册入口，却没有删除账号入口。

我最近看到的 appstore-review-skill，解决的就是这种提审前的焦虑。

它是一个 Claude Code 插件，进项目后跑 /appstore-review，就会按 App Store Review Guidelines 扫一遍项目。

这类工具最舒服的地方，是它不装懂业务，只盯发版风险。

一次 30 秒的本地审查，可能省掉一次 24 小时的 App Store 来回。

02 它到底查什么

—

这个 skill 不是只查 Info.plist。

它会先判断项目类型，再按对应框架去找 iOS 相关配置和源码。

README 里列出的支持范围很广：Swift、Flutter、React Native、Expo、Kotlin Multiplatform、.NET MAUI、Cordova、Ionic、Capacitor 和 Unity。

这些点单独看都不复杂。

麻烦的是，它们分散在配置、依赖、字符串、页面和支付代码里。

手工查一遍很容易漏掉一个角落。

Agent 做这件事的优势，是它可以把散在项目里的线索连起来。

03 报告好用在哪

—

我喜欢它的一个细节：输出不是一句“你的 app 可能有风险”。

它会给出规则号、问题描述、文件位置和修复建议。

比如它会把问题分成 Critical、Warning、Recommendation。

最后再给一个 READY、NEEDS FIXES 或 HIGH RISK 的结论。

这对团队很有用，因为它天然适合进入发版评审。

这比“凭经验再看一眼”可靠很多。

尤其是外包项目、接手项目、跨平台项目，很多审核风险藏在原生层和业务层之间。

App 审核最贵的坑，常常只是提交前没被看见。

04 放进发版流程

—

我会把它放在三个时间点。

第一个时间点，是功能合并到 release 分支之后。

这时还没打最终包，修配置和补页面成本最低。

第二个时间点，是 TestFlight 内测前。

这一步主要抓 beta 文案、测试链接、staging 服务、debug 开关和占位内容。

第三个时间点，是 App Store Connect 提交前。

这一步把报告当作最后一张清单，尤其看隐私、订阅、登录、账号删除和审核说明。

它不需要改你的工程结构，也不需要你先整理一份长文档。

你只要在 Claude Code 里打开项目，跑命令，看报告，修问题。

这才是 Agent 工具最该做的事：把你已经知道但总会漏的检查，变成每次都能执行的动作。

05 怎么装，怎么用

—

如果不用插件管理器，也可以按 README 用 git clone 的方式装到 Claude 的 skills 目录。

项目 README 写明，这个 skill 基于 2026 年 2 月 6 日版本的 Apple App Store Review Guidelines。

所以我的用法很简单：它负责把常见坑先扫出来，最后仍然要看 Apple 官方规则和 App Store Connect 的当前要求。

它不保证过审。

但它能让你在提交按钮前，多一次很清醒的自查。

如果你的团队每个月都要发 iOS 版本，这个 skill 值得成为固定动作。

——————————————————

公众号：荒岛书生 codedoctor

视频号：荒岛书生 codedoctor

小红书：codedoctor