做 uni-app 项目上架 iOS，最容易让人误判的一点是把所有问题都归因到前端代码或打包工具上。
但在实际工程里，上架失败、安装不了、审核被拒，大多数时候并不是 Vue 代码的问题，而是出现在 Apple 体系对应用资格的要求上
打包能成功，不代表 IPA 就是可上架的
很多 uni-app 项目在 HBuilderX 里云打包顺利，IPA 也能下载下来。
问题往往出现在下一步：
- IPA 安装不到真机
- 上传 App Store Connect 报错
- 审核阶段被拒，理由看起来和代码无关
这时才会发现，打包只是生成了文件，上架需要的是一套完整的签名，以及前后一致、能被 Apple 识别的应用信息
常见问题一：开发环境能装，审核包却被拒
这种情况在 uni-app 项目里很典型。
开发阶段使用的是 Development 描述文件，设备装得上，但一旦用同一套配置打包提交，就会被 Apple 拒绝。
工程上需要确认的点包括：
- 是否切换为 App Store 类型描述文件
- 使用的是否是 发布证书（Distribution）
- Bundle ID 是否和 App Store Connect 中完全一致
在 Windows 环境下，我通常直接用 AppUploader 的证书管理与描述文件管理功能 来做区分管理，避免在同一个项目里混用开发和发布配置。
常见问题二：证书明明有，但上传时提示无效
uni-app 项目经常是多人协作，证书问题容易被放大。
典型场景包括：
- 证书在 A 电脑生成，B 电脑打包
- p12 密码遗失
- Keychain 不可用（非 Mac 环境）
工程上更稳定的做法是：
- 统一用工具生成并托管证书
- 明确证书用途（开发 / 发布）
- 描述文件只关联必要的证书和设备
AppUploader 在这里承担的角色不是帮你生成证书，而是减少证书与机器、个人环境的绑定关系。
常见问题三：IPA 上传失败，但错误信息不明确
uni-app 项目在上传阶段，失败率并不低，尤其是在 Windows 环境。
常见原因包括：
- 网络不稳定导致校验失败
- 双重认证未正确配置
- 使用了不兼容的上传工具
在工程实践中，我一般会准备两种方案：
- iTMSTransporter（命令行）
- AppUploader 的提交上传功能
后者的优势在于：
- 内置 Apple 登录与专用密码配置
- 提供多个上传通道
- 上传失败时能更快定位是网络问题还是包本身问题
常见问题四：测试能装，审核却卡在隐私或能力声明
uni-app 项目常用到的能力不少：
- 相机
- 相册
- 定位
- 网络访问
这些能力如果 Info.plist 中声明不完整，审核阶段会直接被拒。
问题不在 uni-app 本身，而在：
- 描述是否和实际行为一致
- 是否声明了未使用的能力
- 是否遗漏了用途说明
在没有 Xcode 的情况下，这类问题往往容易被忽略，需要在打包前就确认配置项。
常见问题五：截图、版本信息、构建号被忽视
这是 uni-app 项目第一次上架时非常容易踩的坑。
- 构建号未递增 → 上传直接失败
- 截图尺寸不匹配 → 审核被拒
- 版本描述过于笼统 → 要求补充说明
工程上，这些并不是“非技术问题”，而是上架流程的一部分。
我一般会：
- 在提交前固定一个 checklist
- 截图使用批量工具处理
- 确保版本号和构建号始终变化
为什么 uni-app 上架问题看起来很复杂，但其实有规律
复盘多个项目后，会发现这些问题有一个共性，它们都发生在代码之外，却决定了代码能否被成功提交
uni-app 降低了开发门槛，但 Apple 并没有因此降低审核标准。
从实际开发经验来看更稳定的做法
与其每次踩坑，不如在流程上做约束：
- 证书、描述文件统一管理
- 开发与发布配置明确分离
- IPA 生成、测试、上传各自独立验证
- 工具只在“适合的位置”介入