我注意到一个现象，聊到 iOS 发布，不少人卡在"打包完成之后"：代码写完了、Xcode 里也能跑了，但要从手上这个项目变成 App Store 里能下载的 App，中间还有一长串环节——App 记录、证书、描述文件、签名打包、上传、提审，每个环节都牵扯不同的账号、文件和工具，任何一个没对上，发布就停在原地。iOS 应用发布流程详解这类资料散在各处，串起来看容易漏。这篇把整条链按环节拆开，每个环节做什么、用什么、卡在哪，一次说清。
一、准备阶段：账号、Bundle ID 和 App 记录
发布的前提是开发者账号——个人账号和公司账号在这一步没差别，都是按年续费，区别在后面：公司账号能加团队成员、共享证书和描述文件，个人账号只能自己用。接着是 Bundle ID：App 的唯一标识，在开发者后台创建 App 时申请，格式是反向域名（com.example.myapp）。Bundle ID 定下来就别改，之后证书、描述文件、上传、提审全部围绕它展开，换一个等于整条链重走。
然后是 App Store Connect 里建 App 记录：进 My Apps 点新建，选平台，填 Bundle ID、名称和默认语言，App 图标、截图可以后面补。这一步没做的话，后面传 IPA 会直接提示找不到对应的 App——顺序不要搞反，先建记录再传包。
注册开发者账号后要等苹果审核，一般 1-2 天；App 记录里的基本信息（名称、副标题、关键词）提交审核时才用到，但提前想好能省后续返工。
二、证书与描述文件：发布专用的两件套
iOS 的签名体系分开发、发布两套：日常真机调试用 Development 证书加开发描述文件，发布走 Distribution 证书加 App Store 类型的描述文件。证书在开发者后台生成，私钥留在生成它的那台 Mac 的钥匙串里，换机器要把证书导出成 .p12 带过去；描述文件在开发者后台按 App ID 和证书生成，App Store 类型不需要勾选设备——上传后由苹果自己分发，这是它和 Ad Hoc、开发描述文件的根本区别。
这块的坑集中在类型选错：用 Ad Hoc 或 Development 描述文件打的包，上传后会被苹果退回来，报签名不匹配。打包前在后台确认描述文件是 App Store 类型，是这条线上最常见的返工原因。
证书和描述文件都有有效期，证书一年，描述文件跟随证书；到期后在后台重新生成即可，不影响已发布版本的正常运行。再提醒一句：免费 Apple ID 只能做真机调试，App Store 发布必须付费开发者账号，这一步没有绕过路径。
三、构建安装包：两条路通向同一个 IPA
产物是同一个东西——签名正确的 IPA。区别在怎么生产。
Mac 上最标准的路径是 Xcode：Product → Archive 归档，Export 时选 App Store 分发，导出选项由 exportOptions.plist 控制（签名方式、分发类型都在里面）。功能最全，代价是环境和操作都绑在 Xcode 上，Windows 和 Linux 用不了。
另一条路是跨平台 IDE 一键构建： KXApp（快蝎） 内置编译工具套装，开发完点一键构建，直接生成适用于测试、分发或提交 App Store 的安装包，不需要安装 Xcode、不需要维护 xcodebuild 参数。Swift、Objective-C、Flutter 三类项目都是同一个按钮。如果你在 Windows 或 Linux 上做 iOS 开发，这条是唯一的选择——Xcode 那套在非 macOS 上跑不起来。
构建时把版本号对好：CFBundleShortVersionString 是展示版本（1.2.0），CFBundleVersion 是构建号（12），两个的组合在苹果侧是唯一键，重复上传会被拒。Export 时选 App Store 分发，包上带的就是发布签名；同一份产物要发给内测或走企业分发，用的是另一套签名体系，和发布流程互不干扰，打包这一步只需要确认 Export 方式选对。
构建环节的产出标准是"签名正确的 IPA"，用 Xcode 还是内置工具链，看你的环境和偏好。
四、上传 IPA：提交到 App Store Connect
IPA 生成后要提交到 App Store Connect 才能进入审核流程。macOS 上常用 Xcode Organizer 直接上传，或者 Transporter 拖文件；命令行环境用 altool：
1xcrun altool --upload-app -f App.ipa -t ios -u dev@example.com -p abcd-efgh-ijkl-mnop
参数逐个看：-f 指 IPA 路径，-t ios 指定平台，-u 是 Apple ID 邮箱，-p 用 App 专用密码而不是账号登录密码——专用密码不触发双重验证，脚本和无人值守的构建机上才能跑得通。
上传常见的错误两类：ITMS-90189 是版本号组合重复，之前传过同一个版本号，改构建号重新打包；找不到对应的 App 记录，回到第一步确认 Bundle ID 和记录一致。上传工具还有图形界面的 Transporter，以及已下线的 Application Loader，选顺手的一个就行。
上传成功后，苹果后台处理需要几分钟到几十分钟，处理完构建版本才会出现在 App Store Connect 的"构建版本"列表里——刚传完看不到属于正常，不用反复重传，更不要因此改构建号重新传。
容易误解的一点：上传成功只代表苹果收下了包并通过初步校验，不等于提交审核。构建版本列表里出现那个包之后，还要手动选中它去提审。
五、提交审核与发布
构建版本就位后，进 App 记录提交审核：选构建版本，填审核资料——App 图标、截图、隐私政策链接、权限用途说明、App 分类和年龄分级。这几项缺了会被直接退回，提交前用 App Store Connect 的审核信息页自查一遍。
审核状态的变化路径是固定的：等待审核 → 审核中 → 通过或拒审。着急上线可以申请加急审核，但理由要充分，审核方会评估，别把它当普通通道用。通过后状态变成"等待发布"，不会自动上线，要手动点发布，或者提前设置自动发布。排期发布的人，提交前就把版本号、上线时间规划好；被拒审了看邮件里的原因，按说明改完重新提交，不用重新走前面四个环节。
发布前建议先在 TestFlight 把包分发给内部测试，真机跑一遍再提审——TestFlight 用的是 App Store 类型的构建版本，等于提前验证了整条发布链，比审核通过后再发现问题省事。
各环节怎么选工具
整条链的工具是组合出来的：签名管理用 Xcode 或跨平台工具都行；构建用 Xcode 或内置工具链；上传用 Transporter、altool 或图形上传工具。组合的灵活性在这里体现：有人用 Xcode 打包加 Transporter 上传，有人全程脚本（xcodebuild 加 altool），有人用跨平台工具链——KXApp 把"构建"这一环做进 IDE，产物直接交给上传环节，省掉的是一整套 Xcode 环境；手上已有成熟的 Xcode 流程，继续用就是，两边不冲突。
按这个顺序走发布流程：先建 App 记录，再准备 Distribution 证书和 App Store 描述文件，打包前确认描述文件类型和版本号组合，上传后等构建版本出现，最后选版本提审。每一步验证通过再进下一步，返工最少。