【免费下载链接】App-Store-Connect-CLIFast, scriptable CLI for the App Store Connect API. Automate TestFlight, builds, submissions, signing, analytics, screenshots, subscriptions, and more项目地址https://gitcode.com/gh_mirrors/ap/App-Store-Connect-CLI点击查看免费下载本文基于 App Store Connect CLI 仓库中的 publishing-process-simplification.md 架构决策系统梳理了发布命令体系从「多路径并行」收敛为「单一规范答案」的完整过程。你将掌握asc publish appstore、asc release stage、asc publish testflight、asc validate、asc submit status|cancel各自的定位与适用场景理解asc release run与asc submit create为何降级为兼容迁移路径并学会如何在不中断存量自动化脚本的前提下平滑迁移到新命令体系。背景两条造成混乱的 App Store 命令路径在命令收敛之前面向 App Store 的发布操作存在两个让人困惑的高层入口asc release runasc submit create两者虽然都能把应用发布到 App Store但各自承担的职责边界模糊release run把「预提交准备」与「真正提交审核」揉进了同一条流水线而submit create则把「创建审核提交」这一底层资源操作误当成了「发布」的唯一途径。结果是新手面对两个都能发布的命令无从选择自动化脚本则因路径混用而难以统一维护。按照新的架构决策docs/architecture/publishing-process-simplification.md这两条路径仍然可用但身份降级为「带弃用警告的兼容迁移路径」——不再被文档、帮助文本或 Agent 教学材料作为「如何发布到 App Store」的标准答案推荐。真正的高层标准答案是asc publish appstore。标准命令总览Canonical Command Map新的命令体系将「发布」收敛为一张清晰的地图每个命令只回答一个问题命令定位是否提交审核asc publish appstore标准 App Store 发布路径上传 → 建版本 → 应用元数据 → 挂构建 → 验证就绪 → 提交审核通过--submit可选asc release stage标准预提交准备路径只准备不提交否asc publish testflight标准 TestFlight 发布路径否beta 审核通过--submit可选asc validate标准 App Store 提交就绪度检查否asc submit status\|cancel底层提交生命周期工具—asc review ...原生 review-submission 资源管理—其中asc publish testflight与asc publish appstore同属publish顶层命令族internal/cli/publish/publish.go帮助文本直接声明Use: - asc publish testflight for TestFlight distribution - asc publish appstore for the canonical App Store upload submit flow - asc release stage to prepare an App Store version without submitting it使用场景指引Use-When Guidance使用asc publish appstore的场景当你满足以下任一条件时应优先选择asc publish appstore想要发布一个 App Store 版本已有 IPA 或面向构建的 App Store 发布流程想要一条确定性命令一次完成上传 → 确保版本存在 → 应用元数据 → 挂载构建 → 验证就绪 → 提交审核希望命令 Agent 与人类开发者第一个想到的就是它。从实现看这条命令的完整流水线定义在 internal/cli/publish/publish.go 的帮助文本中Workflow: 1. Build locally with Xcode or upload an IPA or macOS PKG 2. Wait for build processing (if --wait) 3. Find or create the App Store version 4. Apply version localization metadata (if --metadata-dir) 5. Attach the build to the version 6. Optionally submit for review with --submit --confirm其实际调用链internal/cli/publish/publish.go依次为上传构建uploadBuildAndWaitForIDFn/uploadPKGBuildAndWaitForIDFn底层走/v1/buildUploads与/v1/buildUploadFiles→ 等待处理waitForPublishBuildProcessingFn→ 查找或创建版本findOrCreatePublishAppStoreVersion先按filter[versionString]查/v1/apps/{id}/appStoreVersions不存在则创建→ 应用元数据applyPublishVersionMetadataFn→ 挂载构建PATCH/v1/appStoreVersions/{id}/relationships/build→ 提交审核。提交环节复用submitcli.LookupExistingSubmissionForVersion先探测已有提交避免重复创建internal/cli/cmdtest/publish_appstore_submit_test.go 用 HTTP 级测试完整验证了这套现代 review-submission 流程。典型命令示例# 最简发布上传 IPA 并确保版本存在不提交 asc publish appstore --app 123 --ipa app.ipa --version 1.2.3 # 完整发布应用元数据目录并提交审核 asc publish appstore --app 123 --ipa app.ipa --version 1.2.3 \ --metadata-dir ./metadata --submit --confirm # macOS 平台上传 .pkg 需要同时给出版本与构建号 asc publish appstore --app 123 --pkg MacApp.pkg --version 1.2.3 --build-number 42 # 先预览计划不产生任何上传/提交副作用 asc publish appstore --app 123 --ipa app.ipa --version 1.2.3 --submit --dry-run使用asc release stage的场景当你想要与publish appstore相同的高层准备流水线但尚未准备好提交时使用asc release stage。它专门用于「把元数据与构建挂载先阶段化留给之后的手动或自动化审批步骤」。其帮助文本internal/cli/release/stage.go给出的确定性流水线为1. Verify --build-id exists, belongs to --app, and matches --platform 2. Ensure/create version 3. Apply metadata/localizations or copy metadata from another version 4. Reconcile routing app coverage when --routing-coverage-file is set 5. Attach selected build 6. Run readiness checks关键点是「Stops before creating a review submission」——它止步于创建审核提交之前天然适合分阶段发布。# 预览计划不产生任何变更 asc release stage --app APP_ID --version 2.4.0 --build-id BUILD_ID \ --copy-metadata-from 2.3.2 --dry-run # 从旧版本复制元数据并确认执行 asc release stage --app APP_ID --version 2.4.0 --build-id BUILD_ID \ --copy-metadata-from 2.3.2 --confirm # 从元数据目录应用本地化并确认执行 asc release stage --app APP_ID --version 2.4.0 --build-id BUILD_ID \ --metadata-dir ./metadata/version/2.4.0 --confirm注意release stage有两条互斥的元数据来源--metadata-dir应用本地元数据目录与--copy-metadata-from从指定源版本字符串复制两者必须且只能选其一校验逻辑见 internal/cli/release/stage.go。--copy-fields支持description, keywords, marketingUrl, promotionalText, supportUrl, whatsNew字段级筛选。使用asc publish testflight的场景正在向 TestFlight 分发 beta 版本想要一条「IPA 优先」的高层 beta 交付流程。该命令同样支持预构建产物上传--ipa/--pkg、直接挂载已有构建--build-id/--build-number以及本地 Xcode 构建--workspace/--project/--scheme。典型示例internal/cli/publish/publish.go# 仅上传构建并等待处理完成输出 JSON asc publish testflight --app 123 --ipa app.ipa --upload-only --wait --output json # 上传并加入 beta 分组然后通知测试者 asc publish testflight --app 123 --ipa app.ipa --group External Testers --wait --notify # 上传、加入分组并提交 beta 审核--confirm 必须与 --submit 成对出现 asc publish testflight --app 123 --ipa app.ipa --group External Testers --submit --confirm # 直接复用已有构建 ID 分发 asc publish testflight --app 123 --build-id BUILD_ID --group GROUP_ID --wait使用asc submit ...的场景submit子命令组现在回归「生命周期工具」的定位internal/cli/submit/submit.go需要查询提交状态或取消提交正在调试审核状态维护尚未迁移asc submit create的旧直接提交脚本。submit的帮助文本明确指向了新路径Use: - asc publish appstore --submit for the canonical high-level App Store shipping path - asc validate for canonical readiness checks before submission - asc submit status/cancel for lower-level review submission lifecycle work使用asc release run的场景asc release run仅在以下情况使用维护仍在调用旧 release 命令组的存量自动化在迁移窗口期内需要一条兼容路径逐步过渡到asc publish appstore。它保留完整的阶段化运行能力validate_build→ensure_version→apply_metadata→apply_routing_coverage→attach_build→validate_readiness见 internal/cli/release/run.go但从教学与推荐角度已不再是首选。另外asc submit preflight仍保留为弃用兼容包装供仍期待旧式 preflight 输出的脚本使用——新的就绪度检查请改用asc validate。使用asc review ...的场景需要直接访问 review-submission 资源、items、attachments 或历史记录进行高级或 API 形态的审核工作流调试。它属于底层资源操作不承载「发布」语义。为什么publish appstore是 App Store 发布的标准命令原架构文档给出了六条理由结合源码可以逐条印证匹配真实用户意图用户想做的就是「发布一个 App Store 版本」命令名直接表达了意图asc publish appstore的帮助文本第一行就是 Use this as the canonical high-level App Store publish commandinternal/cli/publish/publish.go。与 TestFlight 共用publish顶层分类publish testflight与publish appstore并列在同一个命令族下internal/cli/publish/publish.go顶层心智模型保持一致用户不必在release与submit两个互不相干的命名空间里分别记忆 App Store 与 TestFlight 的入口。包含用户常忘记的周边步骤直接跳去提交的人常常漏掉「确保版本存在」「应用元数据」「挂载构建」。publish appstore把 upload → ensure version → metadata → attach → validate → submit 串成一条确定性流水线从机制上堵住遗漏。让 CLI 与文档、Agent 预期对齐publishing_canonical_surface_test.go专门断言了这一点——publish帮助必须列出appstore子命令并出现 asc publish appstore 字样submit帮助必须隐藏create与preflight转而出现 asc publish appstore --submit 与 asc validateinternal/cli/cmdtest/publishing_canonical_surface_test.go。把release run保留为迁移垫片而非学习主路径兼容性得到保留但帮助文本与示例不再把它当作教学入口。让submit专注生命周期职责status/cancel承担提交状态查询与取消不再被同时当作「发布命令」与「提交调试命令」双重身份使用职责单一化。迁移政策Migration Policy迁移窗口期内的四条硬性政策保留asc release run可运行触发时给出弃用警告保留asc submit create可运行触发时给出弃用警告在主要发现入口primary discovery隐藏弃用的 App Store 入口即帮助文本不再默认展示它们在帮助文本、模板、迁移提示、示例与 CI 文档中统一优先推荐asc publish appstore。源码对「隐藏 警告」的执行很严格submit命令对create/preflight两个旧参数直接拒绝并输出错误指引Error: asc submit create was removed. Use asc review submit for already-uploaded builds, or asc publish appstore --submit for the full shipping path.见 internal/cli/submit/submit.gopublishing_canonical_surface_test.go则断言submit帮助列表不包含preflight与createinternal/cli/cmdtest/publishing_canonical_surface_test.go确保旧入口从「可见可教」变为「仅作兼容」。对 Agent 与 CI 场景迁移提示同样被测试覆盖auth_doctor_test.go断言迁移建议中不出现release run与submit create引导internal/cli/cmdtest/auth_doctor_test.go避免旧路径通过诊断建议「复活」进新工作流。深度补充publish appstore的完整参数与输出契约参数速查表以下参数来自publish appstore的 FlagSet 定义internal/cli/publish/publish.go参数默认值说明--app必填或ASC_APP_ID环境变量App Store Connect app ID--ipa空预构建 .ipa 路径版本与构建号可自动从 IPA 提取--pkg空预构建 macOS .pkg 路径必须搭配--version与--build-number--version空App Store 版本字符串传--ipa时默认取 IPA 内版本传--pkg时必填--build-number空CFBundleVersionIPA 自动提取--pkg必填--platformIOS取值IOS, MAC_OS, TV_OS, VISION_OS--metadata-dir空元数据目录version/version/*.json在确保版本存在后应用--submitfalse挂载构建后提交审核--confirmfalse确认提交与--submit成对缺一报错--dry-runfalse只预览高层发布计划不上传、不提交--waitfalse等待构建处理完成--poll-interval全局默认轮询间隔--wait与构建发现的轮询周期--timeout默认 30 分钟上传 处理超时带--submit时同样约束提交阶段如30m几个关键的参数校验约束internal/cli/publish/publish.go--submit与--confirm必须成对出现--submit无--confirm报 Error: --confirm is required with --submit仅--confirm无--submit也报错--dry-run模式例外允许只预览提交计划--ipa与--pkg互斥不带任何产物参数时既非 IPA 也非 PKG也非本地构建模式报 Error: --ipa or --pkg is required--poll-interval必须大于 0--timeout不能为负。结构化输出契约命令输出由asc.AppStorePublishResult定义internal/asc/publish.go可通过--output json获取机器可读结果{ mode: ipa_upload, dryRun: false, buildVersion: 1.2.3, buildNumber: 42, buildId: build-42, versionId: version-1, submissionId: submission-1, uploaded: true, attached: true, submitted: true }mode字段取PublishMode枚举之一internal/asc/publish.goexisting_build复用已有构建、ipa_upload上传 IPA、pkg_upload上传 PKG、local_build本地 Xcode 构建。本地构建模式下还会嵌套输出archive/export/publish三个阶段的明细结果PublishArchiveStageResult、PublishExportStageResult、AppStorePublishStageResultinternal/asc/publish.go方便 Agent 分阶段检查。构建处理状态则按PROCESSING/FAILED/VALID/INVALID四态轮询internal/asc/publish.go。release stage参数速查表来自 internal/cli/release/stage.go参数说明--appApp ID或ASC_APP_ID必填--versionApp Store 版本字符串必填--build-id要挂载的构建 ID必填--metadata-dir要应用的元数据目录--allow-deletes允许破坏性删除操作同时禁用缺失语言环境的默认回退--routing-coverage-file就绪度检查前要协调的路由覆盖 GeoJSON 文件--copy-metadata-from从该源版本字符串复制本地化元数据--copy-fields/--exclude-fields复制字段的白名单/黑名单--platformIOS, MAC_OS, TV_OS, VISION_OS默认IOS--timeout阶段化流水线最大运行时长默认 30 分钟--dry-run只预览确定性计划不产生变更--confirm确认阶段化变更非--dry-run时必填--strict-validate把就绪度警告视为阻塞错误--checkpoint-file可恢复运行的检查点路径总结与迁移检查清单收敛后的发布心智模型可以浓缩为四句话要真正发布到 App Store→asc publish appstore ... --submit --confirm只做提交前准备→asc release stage ... --confirm或先--dry-run预览提交前先体检→asc validate调试提交状态→asc submit status|cancel底层资源操作 →asc review ...。迁移检查清单对照 docs/architecture/publishing-process-simplification.md新脚本一律使用asc publish appstore不再新写asc release run/asc submit create调用存量 CI 与脚本中的release run保留运行但关注弃用警告规划时间窗切换需要旧式 preflight 输出的脚本继续用asc submit preflight弃用包装新逻辑改用asc validate帮助文本、模板、迁移提示与文档示例统一引用asc publish appstoreAgent 工作流首选publish appstore仅在调试阶段下钻到submit/review。如果你想进一步了解各命令的完整帮助文本与更多示例仓库内的 commands/publish.mdx、commands/release.mdx、commands/submit.mdx 与 commands/validate.mdx 提供了面向用户的最新文档对应的实现与测试证据集中在 internal/cli/publish/publish.go、internal/cli/release/stage.go、internal/cli/submit/submit.go 与 internal/cli/cmdtest/publishing_canonical_surface_test.go。赞分享【免费下载链接】App-Store-Connect-CLIFast, scriptable CLI for the App Store Connect API. Automate TestFlight, builds, submissions, signing, analytics, screenshots, subscriptions, and more项目地址https://gitcode.com/gh_mirrors/ap/App-Store-Connect-CLI点击查看免费下载相关推荐如何用App Store Connect CLI一键发布App Storepublish appstore、validate与review提交生命周期解析如何用App Store Connect CLI一键发布App Storepublish appstore、validate与review提交生命周期解析 A如何用mechanize构建智能网络爬虫5分钟上手的Browser类完全教程如何用mechanize构建智能网络爬虫5分钟上手的Browser类完全教程 想要快速掌握Python网络自动化今天我将为你揭秘一个终极武器——mechanApp Store Connect CLI完全指南一个命令行搞定TestFlight、构建、签名与发布全流程App Store Connect CLI完全指南一个命令行搞定TestFlight、构建、签名与发布全流程 App Store Connect CLI 命上一篇Haystack 2.19 Connectors API 实战用 OpenAPIServiceConnector 与 OpenAPIConnector 桥接 OpenAPI 外部服务下一篇Zola 内容页面Page完全指南文件名规则、输出路径、Front Matter 与摘要机制详解创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考