先判断需求是不是自定 App

一家软件供应商准备把专属客户端交给两家企业客户时，真正要解决的问题通常不是“如何生成一个安装链接”，而是谁能够发现 App、谁负责购买或获取许可、谁把 App 安装到设备。自定 App 的设计正是先把可见范围限定到指定组织，再由这些组织在 Apple Business Manager 或 Apple School Manager 中接收。

如果 App 只服务一个或少数已知企业、学校或机构，并且接收方能提供组织信息，自定 App 往往比公开上架更贴合交付关系。反过来，若希望任何拿到 App Store 链接的人都能访问，需求更接近非公开 App，不能把两者当成同一个按钮的不同名称。

  • 先写明接收方是指定组织还是不确定的有限受众。
  • 确认接收方是否使用 Apple Business Manager 或 Apple School Manager。
  • 把“指定组织可见”与“任何持有直链的人可访问”分开讨论。

三方角色要在配置前写清

自定 App 交付至少涉及开发者、接收组织管理员和设备管理人员。开发者维护代码、App Store Connect 记录与审核提交；接收组织管理员提供组织 ID，并在 Apps and Books 或 Custom Apps 区域处理 App；设备管理人员再决定使用 MDM 分配，还是向合适的用户发放兑换码。

小团队常见的问题是把这些职责压在一个模糊的“客户联系人”身上。更稳妥的做法是交付前列出每个账号的负责人、组织 ID 的来源、审核测试账号的维护者、许可数量和设备范围。这样即使人员交接，也能判断卡点是在 App Store Connect、组织管理后台还是 MDM。

  • 开发者负责 App 记录、二进制文件和审核沟通。
  • 组织管理员负责提供组织信息并接收 App。
  • 设备管理人员负责许可分配、安装范围和回收流程。

组织 ID 是私人可见范围的连接点

Apple 的官方说明允许开发者指定一个或多个组织。实际操作中，接收方管理员可登录 Apple Business Manager 或 Apple School Manager，在偏好设置的注册信息区域查找组织 ID。开发者应让接收方从管理后台直接提供该值，而不是根据公司名称猜测或从旧邮件中抄录。

录入前可以做一次双人复核：核对组织法定名称、组织 ID、负责地区以及 App 应显示给哪些组织。若同一 App 面向多个客户，应把每个组织分别列入交付清单。私人分发的边界来自这些指定信息，而不是靠网页密码或一个未公开的下载页面来代替。

  • 由具备管理员权限的接收方提供组织 ID。
  • 录入前复核组织名称和 ID，避免把 App 暴露给错误组织。
  • 多组织交付时逐一记录，不用笼统客户名称代替。

在 App Store Connect 选择 Private 的时点

开发者在 App Store Connect 的定价与可用性区域选择分发方式时，需要将目标设为 Private，并按接收方情况填写组织 ID 或官方页面所述的相应 Apple Account。Apple 还特别提示，这项选择应在 App 获批前完成，因此不宜把分发方式留到发布当天才决定。

提交前应把 App 名称、Bundle ID、目标平台、组织列表和价格配置放在一张检查表中。若业务方临时要求从私人分发改成公众可见，先回到官方分发设置说明核对可否变更及所需步骤，再安排发布时间；不要假定所有方式都能随时无损切换。

  • 在获批前完成 Private 分发方式与接收组织配置。
  • 保存组织清单与 App Store Connect 配置的复核记录。
  • 分发方式发生变化时先核对官方变更规则。

审核材料要让评审能够进入真实流程

私人可见不等于不需要审核。对于登录后才能使用、依赖企业数据或展示敏感业务字段的 App，开发者需要为 App Review 准备可用的测试账号、样本数据和必要说明。测试环境应覆盖主要流程，同时避免向评审提供真实员工或客户的敏感资料。

可以在提交前按评审视角走一遍：账号是否会过期，验证码由谁接收，后端是否允许评审网络访问，关键功能是否依赖尚未开通的组织权限。若某项能力只能在客户环境中验证，应在审核备注中清楚说明进入路径和可替代的演示数据。

  • 准备稳定的审核账号和不含真实敏感信息的样本数据。
  • 在审核备注中写清登录步骤、角色权限与主要流程。
  • 提交前验证后端、验证码和测试账户的可用性。

组织获取 App 后再选择 MDM 或兑换码

审核通过后，指定组织可在 Apple Business Manager 或 Apple School Manager 的 Custom Apps 区域看到 App。接收方随后可以通过 MDM 向受管设备或用户分配，也可以根据自身管理条件使用兑换码。开发者负责让 App 对正确组织可见，但设备安装和许可发放通常属于接收组织的管理范围。

MDM 适合需要集中分配、撤回和盘点的环境；兑换码更依赖接收方如何保管与发放。选择前应问清设备是否受管、员工是否使用组织账号、离职或设备更换时如何回收访问。文章无法替代组织自身的安全策略，实际方案应由接收方管理员结合官方部署文档确定。

  • 受管设备优先评估由 MDM 统一分配。
  • 使用兑换码时明确保管、发放和异常处理责任。
  • 开发方与组织方分别验收可见性和实际安装。

为什么自定 App 不是普通直接链接

自定 App 的核心限制是指定组织可见，组织再从自己的管理环境中获取和分发。即使兑换码最终让用户完成安装，也不能把这条路径描述成“发一个任何人都能打开的 App Store 直链”。后者对应的是非公开 App：不出现在搜索和榜单中，但知道链接的人可以访问。

区分这两条路径能避免错误承诺。需要按客户组织精确授权、配合 MDM 并由组织管理员管理许可时，围绕自定 App 设计；需要覆盖加盟商、活动参与者或无法纳入组织管理的有限受众时，再评估非公开 App。选择依据是受众和控制方式，不是哪个入口看起来更省事。

  • 自定 App 先限制组织可见，再由组织完成分发。
  • 非公开 App 的直链可由拿到链接的人访问，控制模型不同。
  • 对外沟通时不要混用“私人分发”和“非公开直链”。

交付验收应覆盖可见、安装与后续维护

上线验收不应停在“审核已通过”。开发者需要确认每个指定组织都能看到正确版本，接收方要验证 MDM 或兑换码的分发流程，业务负责人则要检查首次登录、升级和账号撤销。若 App 面向多个组织，至少使用各组织的测试设备分别走完一次，避免只在开发团队账户中验证。

后续更新也应沿用同一责任表：谁提交新版本，谁提供审核账号，谁通知组织管理员，谁检查 MDM 中的新版本分配。遇到访问问题时先记录组织、设备管理状态、App 版本和出现步骤，再分别查 App Store Connect 与组织管理后台，避免用重新签名掩盖分发配置问题。

  • 逐组织验证 App 可见性与安装结果。
  • 把升级、撤回、离职和设备更换纳入交付清单。
  • 故障记录包含组织、版本、设备管理状态和复现步骤。