很多开发者第一次做 iOS App 时，会把主要精力放在功能开发上：页面怎么做、接口怎么接、数据怎么存、体验怎么优化。可真正走到发布阶段才会发现，一个 App 能不能顺利上架，并不只取决于代码写得怎么样。

但其实，从开发到 App Store 发布，中间还有一条很长的链路：Bundle ID→Team→证书→Provisioning Profile→版本号→构建号→Archive→Validate→Upload→TestFlight→App Store Connect 元数据→截图→隐私政策→App Privacy→审核备注→订阅配置→拒审处理。

每个环节单独看都不算复杂，但组合在一起，就会变成独立开发者和小团队反复踩坑的地方。

于是，我做了一个“iOSdev（iosdev-cn）”Skill，就是为了解决这个问题：把 iOS App 开发、构建、签名、测试与 App Store 上架过程中的高频经验，沉淀成一个可以重复调用的 AI Skill，并将这个Skill上传并参与 天禧AI Skills 苍穹共创计划。

不是替你写 App，而是帮你走稳上架流程

“iOSdev（iosdev-cn）” 的定位很明确：它不是一个“自动生成完整 iOS App”的工具，而是一套面向中国区开发者的 iOS 开发与上架流程助手。

当用户询问 iOS 开发、上架、审核、签名、TestFlight、App Store Connect、隐私合规、订阅配置等问题，或者直接输入触发词 `iosdev` 时，这个 Skill 会先确认关键约束，再按流程给出可执行的检查清单。

比如用户可以这样问：

我要上架一个包含订阅和登录的 iOS App，目标市场是中国区，帮我列一份发布前清单。

也可以这样问：

App Store Connect 里的订阅产品加载失败，应该检查哪些地方？

或者：

我准备提交审核，隐私政策、App Privacy 和权限说明需要注意什么？

这些问题如果只用普通 prompt 直接问 AI，很容易得到一份看起来正确、但执行颗粒度不够的回答。比如“注册开发者账号、打包上传、等待审核”。这类答案没有错，但对真正要上架的人来说还不够，因为它没有继续追问 Bundle ID 有没有创建、Build 号是否递增、签名是否匹配、订阅产品 ID 是否和代码一致、隐私政策是不是公开网页、App Privacy 是否和实际行为一致。

而 Skill 的价值就在这里：把那些每次都要重新解释的行业上下文，固化成一套稳定工作流。

iOSdev 覆盖哪些场景

这个 Skill 的主流程可以概括为六步：

1、需求与约束确认

2、开发与构建准备

3、签名与归档

4、测试与验证

5、App Store Connect 准备

6、提交审核与后续处理

在每一步里，它都会把问题拆到开发者真正需要检查的层面。

在开发与构建阶段，它会关注 App 名称、Bundle ID、Team、最低 iOS 版本，以及是否包含推送、后台、定位、相机、麦克风、订阅等能力。依赖管理上，优先建议 Swift Package Manager，因为它更方便审计和维护；如果项目使用 CocoaPods，也会提醒检查 Podfile、workspace 和锁定版本。

在版本管理上，它会区分 `CFBundleShortVersionString` 和 `CFBundleVersion`：前者是用户可见的版本号，后者是每次上传 App Store 都必须递增的构建号。很多上传失败并不是代码问题，而是构建号、签名或依赖兼容性没有提前处理好。

在签名与归档阶段，它会把开发阶段和发布阶段区分开：开发阶段使用 Development 证书和 Development Profile，发布阶段使用 Distribution 证书和 App Store Profile。对于多数开发者，Xcode 的 Automatically manage signing 是更省心的选择；但如果项目有多个 target、多个环境或者团队协作，就必须进一步确认 Team、Bundle ID、Provisioning Profile 是否完全匹配。

在测试与验证阶段，它会提醒开发者不要只在模拟器里跑通，而要用 Release 配置在真机上验证核心功能。上传前最好先 Validate 归档，清理调试开关、测试账号、占位文案、无效按钮，检查网络错误提示和离线场景。很多审核问题并不是复杂技术问题，而是正式包里留下了测试内容或不可用流程。

面向中国区上架场景的细节

App Store 上架本身有很多通用要求，但如果目标市场是中国区，还会有一些更具体的注意事项。

在 App Store Connect 准备阶段，Skill 会提醒开发者检查应用名称、副标题、类别、年龄分级、版权信息、联系信息、应用描述、关键词、技术支持网址、截图和隐私政策。主要语言建议包含简体中文，隐私政策和用户协议也建议提供中文版本。

如果 App 涉及内容分发、UGC、地图定位、医疗、教育、金融、游戏等场景，还要提前评估是否需要额外资质或合规说明。这类问题往往不是等审核被拒后再补材料就能快速解决的，最好在提交前就完成自查。

隐私合规也是 iOS 上架中越来越重要的一环。`iOSdev` 会提醒用户：隐私政策必须是公开可访问的网页，不建议只放 PDF；App Privacy 要如实填写数据收集项和用途；权限弹窗里的说明要和实际功能一致；如果使用追踪或广告，需要评估 ATT 要求；网络请求优先使用 HTTPS，避免随意开启 `NSAllowsArbitraryLoads`；API 密钥不要明文写在客户端，日志里也不要输出用户隐私和密钥。

一句话说，隐私审核最关键的是一致性：App Privacy、隐私政策、应用描述、权限弹窗和实际行为要对得上。

订阅类 App 更需要清单化

很多独立开发者做 App，最终都会走到订阅或 IAP 商业化。订阅看起来只是加一个付费页，但在审核层面，它有一套独立的检查逻辑。

`iOSdev` 单独把 IAP 和订阅配置拆成参考模块，就是因为这里非常容易踩坑.它会提醒用户先在 App Store Connect 里创建订阅组，再创建自动续订订阅。产品 ID 建议使用类似 `{BundleID}.premium_monthly` 这样的结构，避免后续难以维护。配置时需要填写本地化显示名称和描述，选择价格档位，并设置可用国家或地区。

应用内展示时，价格、周期、自动续订说明、订阅权益、试用规则、取消方式、恢复购买和管理订阅入口都要清楚。如果订阅是核心功能，截图和应用描述中也应该能看到订阅入口或付费页。

测试时，需要创建沙盒测试账号，并验证购买成功、恢复购买、续订状态刷新等关键流程。产品加载失败时，优先检查产品 ID 与 Bundle ID 是否匹配，App Store Connect 中的产品状态是否正确，设备是否使用沙盒账号，以及网络和设备购买限制。

这类检查如果写在一次性 prompt 里，用户下次还要重新解释；写进 Skill 里，就可以形成长期复用的审核前清单。

给开发者的建议

首先，我觉得越具体、越真实、越高频的场景，反而越容易做出有价值的Skill。iOS上架就是一个典型例子。它不是最炫的技术问题，但它足够真实：每个准备发布 App 的开发者都会遇到；它足够重复：Bundle ID、签名、构建号、截图、隐私、订阅这些事情每次都要检查；它也足够有边界：可以拆成一套清晰的流程和清单。

其次，类似于后端开发者的部署清单，设计师的交付清单，运营同学可能有的活动复盘清单，产品经理可能有的需求评审清单，都可以制作成 Skill ，成为一套完成的工作SOP，并参加天禧AI Skills 苍穹共创计划，瓜分千万现金大奖。

天禧AI Skills 苍穹共创计划-核心需求场景

1. 重点鼓励方向：学生群体相关、生产力工具、自动执行类Agent、本地文件/设备联动、专业领域智能体、多模态交互
2. 重点场景参考：

天禧AI Skills 苍穹共创计划-激励内容

1、万亿token（普惠激励）：面向所有参与活动的开发者，人人可享！活动期间，Skill正式上线天禧AI，即可获得2万能量值；如果满足当期活动场景，则额外奖励18万能量值。（Token将以天禧专属能量值形式进行发放，1000能量值=1元）

2、千万现金大奖（优质激励）：活动结束后，按综合得分对所有参赛 Skill 进行评选，优质内容瓜分千万现金奖池，更有流量置顶和开发者荣誉标识。

3、付费收益免分润：活动周期内（2026年5月19日—12月31日），付费 Skill 产生的用户付费收益，平台不参与分成，100% 归开发者所有。

4、开发者等级激励：优质开发者将获得天禧AI平台专属等级标识，并优先参与：平台新功能内测与产品规划共创；官方联动推广与案例展示机会。

如果手里有成熟工作流能优化成Skill的开发者，不妨都来参加天禧AI Skills 苍穹共创计划，活动参与入口：

https://open.lenovomm.com/developer/mgmt/appcreate?type=4