mcpField
A
app-release

app-release

github.com/glebis开发40140 次安装1 天前更新
代码仓库

关于 app-release

用于推进 iOS 和 watchOS 应用发布的技能，涵盖签名、归档和上传至 TestFlight。它面向处理 Apple 发布流程的团队，要求逐项验证关卡，并将生产发布和设备测试留给人工完成。

主要功能

  1. 01按顺序核验发布关卡
  2. 02检查 CloudKit 生产环境架构部署
  3. 03准备隐私与出口合规信息
  4. 04自动签名与归档指引
  5. 05TestFlight 导出与上传指引
  6. 06排查 Apple 上传失败

适用场景

  1. 01准备 iOS 或 watchOS 的 TestFlight 构建
  2. 02检查 CloudKit 架构是否已部署到生产环境
  3. 03调查 Apple 上传遭拒的原因

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/glebis/claude-skills --skill app-release

安装后在 Claude Code 中输入/app-release确认已加载。

附带文件references/gotchas.mdreferences/pipeline.md

详细介绍

App 发布（iOS / watchOS → TestFlight / App Store）

将 iOS/watchOS app 从“尚未启动生产发布流程”推进到由 Distribution 签名、正在 TestFlight 中处理的构建版本。难点不在于任何单个步骤，而在于发布流程横跨三个彼此独立的 Web 门户（Apple Developer、App Store Connect、CloudKit Dashboard）以及 CLI 签名技巧，而且**每个关卡都隐藏着只有前一个关卡通过后才能发现的静默故障。**请将整个流程视为一道气闸检查清单：每个关卡都必须经过验证并关闭，才能开启下一个关卡。

适用场景

发布/上线 iOS 或 watchOS app；将构建版本提交至 TestFlight；归档并上传；将 CloudKit 架构部署到 Production；填写 App Privacy 或出口合规信息；配置分发签名；或排查 Apple 上传拒绝问题。

关卡（按顺序执行；每一步都要验证后再继续）

在项目的问题跟踪器中跟踪每个关卡。不要因为门户显示绿色就认定关卡已关闭——请验证底层产物。

  1. **盘点关卡。**列出当前实际尚未完成的事项（从问题跟踪器获取，或根据下方步骤整理）。区分阻止提交到 TestFlight 的关卡和阻止提交到 App Store 的关卡——两者并不相同。
  2. CloudKit → Production（如果 app 使用 CloudKit）。在明确执行 Deploy Schema Changes 之前，Production 中并不存在 Development 索引/记录类型。通过控制面板进行部署，并确认记录类型出现在 Production 环境中。此操作不可逆——请先征得用户确认。
  3. 出口合规。在源文件中（例如 XcodeGen project.yml info.properties）为每个可发布目标（app 和 watch app）加入 ITSAppUsesNonExemptEncryption: false，这样 TestFlight 就不会在每次构建时都提示。
  4. App Privacy。先检查代码中是否使用了分析工具/第三方 SDK/外部网络通信。如果开发者无法访问用户数据（例如，数据仅存于用户的私有 CloudKit 中），则如实选择未收集数据。在 App Store Connect 中设置。提交时再进行发布。
  5. **隐私政策 + Impressum。**App Store 要求提供托管的隐私政策 URL；欧盟/德国运营方还需要 Impressum。在产品网站上添加页面并部署，然后将隐私政策 URL 填入 App Store Connect。
  6. **签名审计。**使用自动签名时，Xcode 会在归档/导出时生成 Distribution 证书和 App Store 配置描述文件——无需手动操作门户。确认团队 ID 和 CODE_SIGN_STYLE: Automatic。
  7. 归档。对内嵌 Watch app 的 iPhone 方案执行 xcodebuild archive，并添加 -allowProvisioningUpdates。（归档时使用 Apple Development 签名；Distribution 证书会在导出步骤生成。）
  8. **导出并上传到 TestFlight。**使用 app-store-connect 方法、自动签名以及 App Store Connect API 密钥执行 xcodebuild -exportArchive。密钥必须具有 Admin 角色——Developer 角色的密钥无法进行云端签名，会报错："Cloud signing permission error / no iOS Distribution cert found."
  9. 移交设备测试。最后的 TestFlight 验证（安装已处理的构建版本，并在 Production 上测试真实功能流程）必须由人工在设备上完成。不要声称已完成此步骤。

请阅读 references/pipeline.md，了解上述每个关卡所需的确切命令、ExportOptions.plist 和验证单行命令。

任何步骤遇到含糊不清的 Apple 错误时，请先阅读 references/gotchas.md — 其中汇总了实际发布中遇到的静默故障（SwiftPM 检出损坏、Developer 角色的 API 密钥、缺少 CFBundleShortVersionString、iPad 方向设置导致的 90474），并提供了确切的修复方法。

安全护栏（不可妥协）

  • 执行不可逆的生产操作前先确认：CloudKit Deploy to Production 和 App Privacy Publish。这些操作会影响已发布产品的用户／公开产品页面。
  • 绝不打印密钥值。 将 .p8 密钥保存在 ~/.appstoreconnect/；使用后清理所有临时副本。
  • 使用 trash，绝不使用 rm。
  • 通过浏览器自动化操作已登录的门户；绝不输入 Apple 凭据。 请用户在自动化浏览器中登录一次。
  • 将设备端功能循环测试以及最终的 Publish / Submit-for-review 留给人工完成。
  • 仅在专注的提交中提交与发布相关的更改；绝不将分支中无关的 WIP 一并纳入发布提交。

工具说明

  • 门户操作（CloudKit Dashboard、App Store Connect、Apple Developer）最好通过持久登录的浏览器（例如 browser-mate 技能）完成，这样用户只需登录一次，登录会话便会保留。
  • 繁重的构建／签名／上传步骤应在 Shell 中运行（xcodebuild），而非通过 GUI 点击操作——CLI 会提供真实的错误输出，而不是进度条。仅在确实需要时使用计算机操作／GUI。
  • 在后台运行耗时较长的 xcodebuild 步骤，并轮询 ARCHIVE SUCCEEDED / EXPORT SUCCEEDED / Upload succeeded 标记。

评论

支持 Markdown