新增订阅已经在 Sandbox 或 TestFlight 中测试成功，却无法独立送审，通常不是 StoreKit 代码出错，而是商品仍处于该类型的首次提交阶段，或订阅组、App 版本没有组成符合规则的审核提交。
最快判断：2026 年应从内购或订阅详情页使用 Add for Review 建立提交；每种内购类型的首个商品仍要随新的 App 版本共同送审。只有同类型商品已经有获批记录，且 App 存在已批准版本时，后续商品通常才可以不绑定新版本单独提交。
这篇文章适合首次添加消耗型、非消耗型内购或订阅的独立开发者，也适合准备增加新档位、新订阅，或使用远程 Mac 完成构建和上传的小团队。若当前只想学习 StoreKit 编码，而不涉及 App Store Connect 审核组合，本文不会展开完整开发教程。
最后更新于 2026 年 8 月 29 日，流程与版本信息核实自 Apple 的 内购提交帮助、App Store Connect 发布说明 和 App 提交要求。
提交前的资格判断
提交前最重要的不是先点击按钮，而是确认商品是否已经越过“该类型首个商品”的边界。Apple 会分别判断消耗型、非消耗型、自动续期订阅和非续期订阅，不能因为账号里已经存在某一种获批商品，就推断其他类型也具备独立提交资格。
| 判断项目 | 需要确认的内容 | 对提交方式的影响 |
|---|---|---|
| 商品类型 | 消耗型、非消耗型、自动续期订阅或非续期订阅 | 每种类型分别判断首次提交 |
| 同类型历史 | 该类型是否已有商品获批 | 其他类型商品获批不能替代本类型记录 |
| App 版本状态 | App 是否已有批准版本 | 后续商品单独提交通常需要这一前提 |
| 订阅组状态 | Subscription Group 是否已经随版本审核 | 首次订阅通常要将订阅组和至少一个订阅一起送审 |
如果商品是某一类型的第一个项目，就应准备新的 App 版本，并把商品与版本放进同一份审核提交。已有一个消耗型商品，并不代表第一个自动续期订阅可以绕过版本审核；已有非消耗型商品，也不能替代自动续期订阅的首次获批记录。Apple 对首次内购项目和后续内购项目设有不同的提交条件，具体边界可参考 Submit an In-App Purchase 的官方规则。
对于自动续期订阅，还需要确认订阅组。首次提交时，新的 Subscription Group 与至少一个订阅商品通常要和 App 版本共同进入审核草稿；只建立订阅商品、完成测试购买，并不等于订阅组已经具备正式送审条件。
为什么已经测试成功的新增订阅仍然不能单独送审？
常见原因有三种：它是该订阅类型的第一个商品；订阅组还没有获批；或者当前 App 没有已批准版本。除此之外，商品资料没有通过 Add for Review 加入提交草稿，也会让开发者误以为系统不支持独立送审。
Sandbox 或 TestFlight 的成功购买，只能证明测试环境里的交易流程基本可用。审核还会检查商品名称、描述、价格、销售地区、审核截图、购买入口和 Review Notes，因此测试成功不能替代审核元数据准备。
审核资料与草稿准备
在进入 Add for Review 之前，先把商品资料补齐。建议在商品详情页逐项核对以下内容：
- [ ] Product ID、商品类型和显示名称已经确认，没有把测试项目当成正式商品。
- [ ] 本地化名称和描述已经填写，内容与 App 内展示一致。
- [ ] 价格等级和销售范围已经设置，目标市场没有被意外排除。
- [ ] 已上传内购审核截图，能够展示商品入口和购买后的实际内容。
- [ ] Review Notes 说明登录方式、购买入口、测试步骤和解锁结果。
- [ ] 自动续期订阅已经关联正确的 Subscription Group。
- [ ] 正式构建中的购买入口可以访问，而不是只有 Debug 开关才显示。
- [ ] 登录账号、后台接口和付费内容在审核期间保持可用。
Apple 要求内购项目提供审核所需的截图和说明，相关资料应在 内购信息编辑与审核资料说明 中核对。截图不是 App Store 页面宣传图，而是帮助审核人员理解商品入口和实际购买流程的材料。
如果 App 需要登录才能看到购买页面，Review Notes 必须写清楚账号信息和操作路径。若商品购买后需要服务器同步权益，也要说明审核账号能否立即获得结果，避免审核人员完成付款后无法看到内容变化。
Add for Review 的提交组合
Add for Review 位于目标 App 的 Monetization 区域。内购项目通常从 In-App Purchases 进入，订阅则从 Subscriptions 进入；打开具体商品详情后，可以将商品加入已有草稿，也可以创建新的审核提交。
建议按照以下顺序操作：
- 在 Apps 中选择目标 App，并确认平台为 iOS。
- 进入 Monetization 下的 In-App Purchases 或 Subscriptions。
- 打开需要提交的商品，检查商品类型、Product ID 和订阅组。
- 选择 Add for Review，将商品加入现有草稿，或建立新的提交。
- 如果系统要求新版本，选择已经准备好的 App 版本。
- 首次提交自动续期订阅时，同时加入 Subscription Group 和至少一个订阅商品。
- 打开提交详情，确认 App 版本、商品和订阅组是否出现在同一份草稿中。
- 检查 Review Notes、截图和购买入口，确认无误后再点击 Submit for Review。
怎样确认内购商品与 App 版本已经组成同一份审核提交？
打开提交详情后，不要只看商品是否显示为 Ready for Review，而要核对提交对象列表。首次内购应同时看到对应的 App 版本和首个商品；首次订阅还应看到订阅组与至少一个订阅商品。只看到商品资料完成，并不能证明版本关联已经完成。
对于同类型下已经有获批商品的后续项目，系统可能允许建立不含新 App 版本的商品提交。此时仍应确认当前 App 已有批准版本，并检查提交对象是否正是本次要审核的 Product ID，而不是误把未发布的新版本加入草稿。Apple 对包含 App 版本的提交和仅包含内购项目的提交分别提供了说明，可参考 提交审核总览。
构建上传与远程 Mac 验收
首次商品需要随新 App 版本送审时，商品草稿只是审核组合的一部分，正式构建同样需要完成上传和关联。构建上传后，应等待处理完成，再在 App 版本中选择正确的 Build。
截至 2026 年 8 月 29 日，正式 App Store 分发应优先采用符合当前提交要求的 Xcode 26 链路。Apple 的提交页面说明，自 2026 年 4 月 28 日起，上传到 App Store Connect 的 iOS 和 iPadOS App 需要使用 iOS 26 SDK 或更高版本构建，实际提交前应再次查看官方要求。
Xcode 27 beta 6 不能直接当作正式商店分发工具使用。根据 Apple 的发布说明，该版本构建目前可用于 TestFlight 内部和外部测试，但截至本文核实日期，不应将其测试支持描述成正式 App Store 客户分发支持。正式发布前，应以 Xcode 支持状态和 App Store Connect 当期要求为准。
使用远程 Mac 时，还要完成本地开发机上通常容易被忽略的恢复验收：
- [ ] 签名证书、Provisioning Profile、Bundle ID 和 Team 属于同一发布链路。
- [ ] 上传凭据有效，且没有把发布密钥散落在多人共享的脚本中。
- [ ] 构建上传后已经从 Processing 进入可选择状态。
- [ ] App 版本中选择了正确的 Build，而不是旧构建或测试构建。
- [ ] 远程连接中断后，重新登录仍能查看构建状态、上传日志和提交草稿。
- [ ] 正式构建中能够加载商品，并能从购买入口进入付款流程。
- [ ] 构建号、提交时间、错误日志和审核编号已经记录。
Apple 对构建状态的定义可参考 App 上传状态说明。Processing 只表示系统仍在处理，不代表构建已经可以被版本选择；看到上传完成后，应先确认 App Store Connect 中的实际状态。
⚠️ 如果远程连接在上传期间中断，不要马上重复增加版本号。先确认 App Store Connect 是否已经收到构建、处理状态是否变化，再决定继续等待、重新上传，还是修复签名与凭据问题。
拒审后的对象处理
一次提交可能同时包含 App 版本、内购商品、订阅组和多个订阅商品。构建已经处理完成，只能说明上传阶段结束，不能说明所有审核对象都已经通过。
审核后应分别查看以下对象：
- App 版本是否 Accepted、Rejected 或仍在审核。
- 内购商品是否被单独指出问题。
- Subscription Group 是否存在待处理状态。
- 审核提交是否仍有未解决对象。
- Messages 中的拒绝原因对应哪个 Product ID 或哪个页面。
商品被拒后，构建是否一定要重新上传？
不一定。如果拒绝原因只涉及商品描述、审核截图、Review Notes、订阅组配置或购买入口说明，而二进制没有发生变化，通常应先修改对应对象，再使用 Update Review 和 Resubmit 重提，不要默认重新上传一份完全相同的构建。
如果审核消息明确指出应用内购买入口在当前构建中不可访问、商品加载失败、购买后权益没有解锁，或问题确实来自代码与二进制，则需要修复项目、递增版本号并重新上传。判断依据应来自 Messages 的具体对象和复现步骤，而不是看到 Rejected 就机械重传。
Apple 的状态说明可参考 App 与提交状态定义。在多个对象共同提交时，应先找出真正阻塞审核的对象，再决定修改资料、更新提交还是重新构建。
可重复的发布流程
内购发布容易在第二次、第三次增加商品时出错，因为开发者忘记某个商品类型是否已经完成首次获批。建议维护一份商品类型登记表，至少记录：
- Product ID 与商品类型。
- 是否属于该类型首个获批商品。
- 关联 App 版本与构建号。
- Subscription Group 和首次获批记录。
- 审核截图、Review Notes 的保存位置。
- 最近一次提交编号、拒绝原因和重提结果。
- 构建上传凭据由谁管理，哪些账号只负责上传。
- 商品资料修改人与审核提交人是否分离。
权限也不应全部集中在日常开发账号上。Apple 的 账号角色与权限说明显示，商品管理通常需要 Account Holder、Admin 或 App Manager 等相应权限；Developer 角色并不自动等于完整的内购管理权限。发布密钥、App Store Connect API Key 和商品编辑权限应按职责拆分。
下一次增加后续商品时，可以把它当作一次发布演练：先判断是否满足独立提交条件，再完成 Add for Review、资料核对、状态跟踪和拒审恢复。若流程只能依赖某一台个人 Mac、某一个人的登录状态或某一份未记录的证书文件，团队仍然缺少可交接的发布能力。
| 场景 | 应采用的流程 | 常见错误 |
|---|---|---|
| 某类型首个消耗型或非消耗型商品 | 新 App 版本与首个商品共同提交 | 因账号已有其他类型商品而尝试独立送审 |
| 某类型首个自动续期订阅 | App 版本、订阅组和至少一个订阅一起提交 | 只提交订阅商品，没有加入订阅组 |
| 已有同类型获批商品后的新增项目 | 符合条件时通过 Add for Review 单独提交 | 只看商品状态，不检查 App 获批版本 |
| 商品资料被拒 | 修改对应对象，Update Review 后 Resubmit | 没有二进制变化也重新上传构建 |
| 构建仍在 Processing | 等待处理并核对状态 | 看到上传完成就马上送审 |
| 交付环节 | 验收重点 | 通过标准 |
|---|---|---|
| 商品资料 | 本地化、价格、销售范围、截图和 Review Notes | 审核人员能复现购买流程 |
| 订阅配置 | Subscription Group 与商品关联 | 首次订阅提交对象完整 |
| 构建上传 | 签名、凭据、处理状态和 Build 选择 | App 版本能选择正确构建 |
| 提交草稿 | App 版本、商品和订阅组 | 对象组合符合首次或后续规则 |
| 审核恢复 | Messages、Update Review、Resubmit | 能定位单个阻塞对象，不盲目重传 |
| 当前环境 | 主要缺点 | 更适合的使用方式 |
|---|---|---|
| 个人 Mac 临时打包 | 不常在线，证书和磁盘状态难以交接 | 发布前专门检查并保留构建记录 |
| 共享开发机 | 多人操作可能覆盖证书、缓存或登录状态 | 限制权限并记录每次上传 |
| 普通云主机 | 无法直接提供完整 macOS 与 Xcode 工具链 | 只承担脚本或非 macOS 任务 |
| 远程 Mac 发布环境 | 需要验证断线恢复和凭据管理 | 在真实内购提交前完成一次恢复演练 |
如果当前方案依赖个人 Mac 临时充当打包机，常见问题是设备不持续在线、Xcode 更新影响环境、签名文件难以交接，以及审核拒绝后无法快速复现构建。普通云主机又不能替代完整的 macOS 工具链，因此并不适合作为长期 iOS 发布节点。
对于只在内购发版、审核复核或短期 CI 阶段需要 Mac 的团队，RUVCLOUD 的远程 Mac 可以作为按需使用的发布环境，减少为了偶发审核任务长期购买和维护实机的负担；但如果团队每天持续进行高负载构建，或必须连接特定物理设备，本地 Mac 仍然更适合长期使用。
完成资格判断后，下一次真实内购发布可以先按 RUVCLOUD 的远程 Mac 发布方案检查 Xcode、签名、上传和断线恢复要求，再根据 RUVCLOUD 的套餐信息选择短期测试或持续发布周期。