★ FEATURED ARTICLE 现象从 10 月 28 日开始用 ios-uploader以及各种转运脚本往 App Store Connect 上传 ipa全部失败报错Found Bundle ID xxx, Version 125 (1.2.5). Unexpected token S, Sign in wi... is not valid JSONHBuilderX 云打包出来的包是正常的问题在上传环节。排查过程第一步确认不是账号/密码问题把同一个 App 专用密码拿去请求 Apple 的 CalDAV 服务认证直接通过HTTP 207。再把这段密码拿去请求上传认证接口contentdelivery.itunes.apple.com的authenticateForSession返回的却是纯文本而不是 JSONSign in with the app-specific password you generated. If you forgot the app-specific password or need to create a new one, go to account.apple.com. (-22938)同一个密码、同一个账号一个通一个不通 —— 说明密码是好的。第二步找到真正原因我一开始判断错了我试了各种变体gzip 压缩、HTTP/2、不同端点、把 API 密钥 JWT 塞进 cookie 或 Bearer 头全部返回同一句话于是误判成「Apple 封了这条通道」。实际情况是Apple 把 User-Agent 的校验改严了必须严格匹配特定格式换成下面这个完整 UA 就通了iTMSTransporter/4.3.0.4 (Windows 11; 10.0; amd64; Java 21.0.5) SmartClient/0.1.0实测对比同一个 App 专用密码[旧 UA] iTMSTransporter/4.2.0 → 被拒 [新 UA] iTMSTransporter/4.3.0.4 (Windows 11; ...) → 拿到 SessionId登录恢复报错信息只提「请用 App 专用密码登录」完全不提 UA误导性极强 —— 原作者 simonnilsson 也是排查了半天才定位到已在ios-uploader v4.0.3修复。这件事真正暴露的风险这类工具依赖 Apple 未公开的内部接口和「魔法字符串」Apple 可以随时悄悄改一次、零预告你就得跟着猜一次。更稳的方案官方 Build Uploads API先说清楚如果只是偶尔传个包ios-uploader v4.0.3 已经修好继续用它完全没问题。下面这条更适合要长期依赖上传流程的场景 —— CI 自动化、团队共用、不想每次 Apple 改内部接口都跟着猜。Apple 有公开文档化的 App Store Connect API其中Build Uploads资源就是干上传这件事的。认证走 API 密钥JWT接口契约是公开的不依赖 UA 格式这类隐形约定POST /v1/buildUploads 登记一次构建上传版本号 / build 号 / platform POST /v1/buildUploadFiles 拿到对象存储的预签名分块上传 URL PUT presigned-url 按分块上传 ipa每块 5MB PATCH /v1/buildUploadFiles/{id} 标记 uploadedtrue → Apple 自动解析出 buildTestFlight / 提审可用注意assetType的有效值是ASSET/ASSET_DESCRIPTION/ASSET_SPI不是IPA。准备App Store Connect → 用户和访问 → 集成 → App Store Connect API → 生成密钥角色选 App Manager 或更高下载.p8只能下载一次记下Key ID和Issuer ID拿到 App 的数字 IDApp Store Connect 后台 URL 里apps/后面那串数字用现成工具我把整个流程写成了一个零依赖的 Node 脚本只用内置模块Windows / macOS / Linux 都能跑已开源GitHub: xxhshenqi/asc-ipa-uploaderGitee: xiaoxianghui/asc-ipa-uploader先装上无需 npm 账号2 秒npm i -g https://github.com/xxhshenqi/asc-ipa-uploader/archive/refs/heads/master.tar.gz用法# 先查 App ID asc-ipa-uploader --key ./AuthKey_XXXX.p8 --key-id XXXXXXXXXX \ --issuer ISSUER_ID --list-apps # 上传版本号 CFBundleShortVersionStringbuild 号 CFBundleVersion asc-ipa-uploader --key ./AuthKey_XXXX.p8 --key-id XXXXXXXXXX \ --issuer ISSUER_ID --app APP_ID --ipa ./xxx.ipa --version 1.2.5 --build 125 # 上传完顺手把版本记录建好、build 关联上之后去后台填更新说明提审即可 asc-ipa-uploader ... --release脚本做了几件省心的事上传前先查同 build 号是否已存在避免白传、API 调用遇到新建密钥的瞬时 401 自动重试、分块上传带进度、传完轮询到 build 状态变 VALID 才退出。实测一个 17MB 的包两三分钟传完并转 VALID。一点提醒.p8私钥不要提交到仓库也不要发群里用环境变量传路径更安全支持ASC_KEY_PATH/ASC_KEY_ID/ASC_ISSUER/ASC_APP_IDApple 不允许重复的 build 号同一个包要重传得先升 build 号想继续用 Mac 官方 Transporter 的不受这次变更影响受影响的是没有 Mac、靠第三方工具传包的场景如果这个工具帮你解决了问题欢迎 star有 bug 或想加功能直接提 issue。
阅读完成 · 觉得有帮助？
