1. Overview
一个应用的诞生大致经过以下历程：
(Idea)想法诞生 --> (Prototype)原型设计 --> (App)应用实体 --> (Users)用户使用
你为了解决某个问题而产生想法，设计了应用的基本样式和页面交互等，然后把原型转换成真正的App，最后给用户使用，本 section 聚焦在最后一个环节，结合应用发布的四个途径，描述如何用最合适的方法将开发好的应用交付到用户使用。
2. Distribution Methods
应用发布总共有四种途径：Ad Hoc、App Store、In-House、Custom Apps
关于途径的选择，你需要考虑很多问题。应用的受众是谁？谁会购买你的应用？应用的归属是谁？应用发布面向的设备是谁持有的？源码的所有权属于谁？编译应用的工作谁负责？需要开发者账号的是谁？归根结底，就是需要明确应用的使用者是谁。
苹果将应用的使用者归类为个人用户和群体用户，面向个人的用户可以选择 Ad Hoc 和 App Store，其中 Ad Hoc 是受限制的私有途径，主要限制了使用者数量和设备，而 App Store 则是四种途径中唯一一个公开的应用发布途径，面向所有个人用户，因此需要经过苹果严格的审核才得以发布。面向群体用户，比方说是一个企业里的员工，可以选择 In-House 和 Custom Apps 的方式发布应用，这两种都是私有的途径。在不同阶段的应用发布可能需要选择不同途径，这就需要你明白应用的预期效果和最优方案，选择最合适你的应用使用场景的途径。在这里苹果通过一个真实的应用例子讲述选择不同途径的情况。
2.1 Ad Hoc Distribution
在完成 App 开发，准备进行发布之前，我们都希望 App 能在周围的同事之间先进行测试，提提意见，修改完善之后再发布到 App Store 上。另外，我们应用可能使用了类似 CloudKit、APNS 等不能通过调试测试的功能，但是又希望能测试到这些功能。Apple 考虑到这些问题，通过 Ad Hoc 来实现发布前的用户测试。使用 Ad Hoc 发布非常简单，配置好 Ad Hoc 证书后打包导出ipa，就可以给别人安装了。但是使用 Ad Hoc 是有限制的，使用 App 的设备需要在开发者账号上注册，一个账号每年最多只能注册100台设备。关于 Ad Hoc 的要点大致如下：
用于在已注册的设备上进行测试；
短期发布的解决方案；
发布的应用不可长期使用，过期后将无法使用；
设备限制每年都会重置一次；
随着测试的规模扩大，Ad Hoc 发布的方法将不能满足需求，一方面是手动添加设备UDID的过程比较耗费时间，另一方面测试设备数量的限制也会限制测试规模的扩大。这时候可以使用 TestFlight 来扩大 Beta 测试的规模。
TestFlight 有分内部测试（Internal Testing）和外部测试（External Testing），内部测试 app 不需要经过审核，只要上传即可，但是只能邀请被添加到团队的成员参加，而且最多只能添加25人。而公测是需要审核的，不过只需要知道对方的邮箱即可发送邀请，而且最多可以邀请10000人。TestFlight 发布的一个版本有效期最多只有90天。
2.2 Submitting to App Store
在完成 Beta 测试后，你对 App 提炼出符合更多用户使用的特性，接下来可以准备宣传的资料、演示视频等，就可以准备上架 App Store，向外发布你的应用了。 App Store 上架的应用面向你选择的商店的所有用户，应用的审核和管理由 Apple 完成，因此你需要了解并遵循 App Store 的审核准则，确保你的应用适合大众使用，并不断更新应用以适配新的设备和系统。
2.3 In-House Distribution
针对企业内部应用，Apple 提供了 In-House Distribution 途径，让你可以完全控制应用发布的整个流程。企业自身拥有并维护应用的源码，不需要上传到 App Store，借助移动设备管理系统（MDM），就可以完全在企业内部完成应用开发到发布使用的整个过程。
In-House 发布方式要求应用的使用者都是企业内部人员，使用 In-House 发布的应用要求设备可以联网，所以无法连接外网的设备可能无法使用。因为应用整个流程都是企业掌控，不能依托 TestFlight等工具，所以对于应用的测试和管理需要企业自行处理好。In-House 所使用的发布证书需要妥善保管，证书有效期只有三年，Provision Profile 有效期只有一年，所以要管理好证书生命周期，及时发布证书更新的应用版本，以免出现过期等情况导致应用失效。如果需要出于某些原因需要撤销证书，那么使用该证书发布的应用会马上失效，企业需要重新签名和发布应用，否则会可能出现非常糟糕的情况。
2.4 Custom Apps
Custom Apps 也是私有的发布途径，主要使用于企业对企业提供定制化的应用服务，负责开发的一方可以在不提供源码的情况下直接提供可购买的 App 给请求开发的一方使用。另外还可以是企业为自己提供，应用可由企业自己开发并在自己的账号上发布。
Custom Apps 属于苹果开发者计划（Apple Developer Program）的一部分，依托 Apple Business Manager 进行管理。此前 Custom Apps 只可用于企业为企业提供定制化应用服务，现在也可以像 In-House 那样企业为自己提供服务，你可以给你的合作伙伴、客户、加盟商、内部员工、分公司等提供应用，通过 MDM 或兑现码分发许可证。
Custom Apps 可在一个平台上管理内部和外部的所有应用，发布的应用没有使用期限，不用担心过期的问题。In-House 发布的应用只能提供给企业内部员工使用，而 Custom Apps 则可以提供给分公司等更多人一起使用。 Custom Apps 本身设定是企业对企业提供服务，因此对于寻求第三方软件服务支持的企业来说，他们无需访问源码就可以获得已发布好的应用，也不需要对应用的二进制包进行重签名等操作。另外，你可以使用 App Store 提供的不断更新的基础设施服务，比如说支付系统、App Thining、TestFlight 和 App Store Connect 工具等特性。
Custom Apps 要求购买应用的用户需要有一个 Apple Businsess Manager 账号，应用需要支持和适配好其选择发布的国家，最好支持所有的国家。如果使用兑换码购买应用，需要确保兑换码只会给到特定的用户，因为兑换码只能在对应企业内可用。Custom Apps 需要经过审核，审核要求可以访问应用所有的功能，审核通过发布后，不能再提交到 App Store 作为公开应用。
Apple 在此环节还描述了如何使用 Custom Apps 发布应用，以及出现问题后解决的几个思路，详情可见视频或官方文档。
3. Summary
综上所述，关于选择途径，主要是根据应用的使用者是对外还是内部进行选择，Ad Hoc 可供内部测试时发布使用，App Store 用于对公众发布，In-House 和 Custom Apps 用于私有应用发布使用。Ad Hoc 途径一般只适用于 Beta 测试，针对发布正式应用的途径选择，Apple 总结成一下表格：
| 使用场景 | App Store | In-House | Custom Apps |
|---|---|---|---|
| 面向公众 | ☑️ | ||
| 不愿向企业提供知识产权 | ☑️ | ☑️ | |
| 企业没有 MDM | ☑️ | ||
| 被雇佣作为应用开发顾问 | ☑️ | ☑️ | |
| 企业没有使用 Apple Business Manager | ☑️ | ||
| App 只面向内部员工 | ☑️ | ☑️ | |
| 为自己的企业发布应用 | ☑️ | ☑️ |
Apps are like cannonballs, it is better to know where they are going before they deploy.
Apple 希望你的应用可以用最明智的方式发布应用，这就需要你考虑清楚你的客户和用户是谁、合理分配对应版本的应用、知道并了解苹果应用审核的准则，从而选出最合适的发布途径。
Section Video
WWDC 2019 Section 304: App Distribution – From Ad-hoc to Enterprise