提交到App Store和Google Play是完全不同的玩法。这里没有单一的"发布"按钮——你需要先在App Store Connect创建应用记录，在Xcode里打包签名好的构建版本并上传，跑一轮TestFlight测试，回答出口合规问题，填写隐私标签，最后才能把应用交给真人审核团队。漏掉其中任何一步，你的构建版本就会在"等待审核"状态里卡好几天，或者因为一个本来可以避免的小错误被拒。2026年的审核管道比以往更加自动化，但核心逻辑没变：记录完整、构建稳定、元数据真实，应用就能快速过审。这篇教程带你走完从空白App Store Connect账号到应用正式上线的每一步。
第一步：前置条件——会员、协议与Bundle ID
在上传任何东西之前，三件事必须就绪：
- 有效的Apple开发者计划会员（个人或组织均为99美元/年）。你的账号必须在App Store Connect里接受最新的Apple开发者计划许可协议——协议过期会阻止一切上传。
- Bundle ID（包标识符）已在开发者账号中注册。使用反向域名格式，例如
com.yourcompany.yourapp。它必须全局唯一，且日后不能被其他开发者复用。 - App Store Connect访问权限，角色需能管理应用——Account Holder（账户持有人）、Admin（管理员）、App Manager（应用管理者）或Developer（开发者）角色都可以提交。
如果你还没注册账号，昨天的文章详细对比了个人、组织与企业账号怎么选，包括组织账号必需的D-U-N-S编号。每年99美元的会员费同时覆盖TestFlight测试和App Store分发。
第二步：在App Store Connect创建应用记录
进入App Store Connect的 我的App → "+" → 新建App，填写以下内容：
- 平台：iOS（如果是通用应用则选择iOS + iPadOS）。
- 名称：用户在商店里看到的显示名称——最多30个字符，且必须与应用的实际功能一致（App Review指南2.3会拒绝误导性名称）。
- 主要语言和 SKU——一个唯一的内部标识符，例如
app20260806。 - Bundle ID：选择第一步注册的那个。
创建记录并不等于提交——它只是创建一个你接下来要填写的空壳。记录可以一直停留在"准备提交"状态，多久都行。
第三步：打包并上传构建版本
在Xcode中，先在项目Signing & Capabilities（签名与能力）标签页设置好签名团队：
- 将目标设备选为 Any iOS Device (arm64)——不要选模拟器。
- 选择 Product → Archive（产品 → 归档），生成一个已签名的可分发构建版本。
- 在Organizer窗口中点击 Distribute App（分发App），目标选择 App Store Connect，按导出流程操作。
- Xcode会自动上传归档包。也可以导出
.ipa文件，用 Transporter 应用上传。
导出过程中，Xcode会询问 出口合规（export compliance）——你的应用是否使用加密。如果只使用标准HTTPS/SSL（绝大多数应用都是如此），可以声明加密豁免（ITSAppUsesNonExemptEncryption = false）直接上传，无需出口证书。如果使用了自定义加密算法，则需要相应的ERN文档。很多第一次提交的开发者都会卡在这一步；标准HTTPS豁免可以覆盖大多数情况。
第四步：提交前先用TestFlight做Beta测试
TestFlight是Apple官方的Beta测试服务，对于第一次发布来说几乎等于必做项。每个应用最多上传 100个构建版本，并且可以同时测试多个。Apple TestFlight文档中的关键信息：
- 内部测试员：最多100名开发团队成员（Account Holder、Admin、App Manager、Developer或Marketing角色）。无需Beta审核，构建版本几乎立即可用。
- 外部测试员：最多10,000人。外部测试需要填写 Beta应用描述 和 Beta审核信息，每个新构建版本都要先通过一次快速的Beta App Review。
- 测试组（Groups）：把测试员组织成多个组，给不同组分配不同构建版本——适合按平台或按功能划分测试轮次。
- 设备：每位测试员最多可在30台设备上安装你的Beta版，无需UDID配置——测试员直接从TestFlight应用安装即可。
测试员通过TestFlight应用反馈崩溃和问题，都会汇总到App Store Connect。这一步不要跳过：真机崩溃日志能抓到模拟器发现不了的Bug，而审核时崩溃的构建版本会直接被拒（指南2.1）。
第五步：填写商店信息与隐私标签
回到应用记录的 版本 区块，提交前把所有字段填完整：
- App Privacy（隐私营养标签）：声明你收集哪些数据类型——联系方式、位置、标识符、使用数据，以及这些数据是否关联用户或用于追踪。声明必须与代码实际行为一致；不一致会在审核中被标记。
- 截图与预览：最大支持设备尺寸的截图必填；如果开启选项，其他尺寸可以自动生成。
- 描述、关键词和更新说明：要真实准确——指南2.3要求元数据与应用真实功能一致。堆砌无关关键词有被拒风险。
- 年龄分级、类别和价格：年龄分级问卷决定商店的年龄门槛；按地区设置价格（或免费）与上架地区。
- App Review信息：你的联系方式，以及——最关键的一点——应用需要登录时提供 演示账号（demo account），并在备注里解释不明显的功能与IAP商品。
App Review指南写得非常明确：测试崩溃和Bug、确保元数据完整准确、审核期间保持后端在线可用、提供演示账号或演示模式、提交前清除占位文本和无效URL。
第六步：提交审核——接下来会发生什么
所有内容填好后，点击 Add for Review（提交审核），构建版本进入队列：
- Apple的自动化检查先跑一轮——二进制有效性、启动崩溃检测、基础元数据校验。
- 随后真人审核员会在真机上测试你的应用，比对元数据与应用行为是否一致，验证演示账号凭据，确认IAP商品可以正常购买。
- 2026年新应用的典型审核时长是几天，更新通常更快。遇到关键时效性修复（比如服务器故障或安全问题）可以申请加急审核，但要慎用。
- 如果被拒，你会收到一条对应具体指南的明确原因。修复问题、升级构建版本号、上传新构建并重新提交。只有在原因不清楚时才需要回复消息追问。
审核通过后，应用不会自动上线——由你决定。把发布方式设为 Manual Release（手动发布），准备好后再点击发布按钮；或者安排在指定日期自动发布。对于重大更新，可以考虑 分阶段发布（phased release），按百分比逐步放量，在全面分发前发现线上问题。
2026年被拒的常见坑，总结如下：构建版本崩溃或存在明显技术问题（2.1）、把Beta版或试用版提交到商店而不是用TestFlight（2.2）、元数据与应用不匹配（2.3）、隐私标签缺失或不准确、占位内容、审核时演示账号失效或后端离线。提交前修掉这五类问题，绝大多数首次被拒都可以避免。
从账号到上线：一条完整流水线
完整流程是：注册开发者计划（99美元）→ 注册Bundle ID → 创建App Store Connect记录 → Xcode归档 → 回答出口合规问题 → 上传 → TestFlight测试 → 完善商店信息与隐私标签 → 提交审核 → 发布。第一次上架的开发者通常把大部分时间花在元数据和审核信息上，而不是构建本身。把这些做对、审核期间保持后端可达，App Store的流程其实相当可预期。