已有Push Notification能力的iOS宿主App新增App Clip时是否需单独配置推送能力与证书？

App Clip 是否需要单独配置Push Notification能力 #

• 完全不需要为App Clip的target单独添加独立的Push Notification capability开关。App Clip是和宿主App强绑定的轻量关联组件，系统层面的通知权限校验、APNs通道连通性，直接继承宿主App已完成的推送能力配置，不存在独立的能力校验拦截逻辑。
• 开发时只要在App Clip的代码里和宿主App保持一致，正常调用UNUserNotificationCenter的权限申请、registerForRemoteNotifications的注册逻辑即可，不会因为App Clip本身没有单独勾选推送开关就被系统拦截推送请求。

是否需要单独为App Clip注册Push SSL证书 #

• 不需要额外申请任何新的APNs相关凭证，你之前为宿主App注册的开发/生产环境Push SSL证书、用于APNs服务端鉴权的Auth Key都可以完全复用，没有任何权限隔离。
• 底层原因是App Clip没有独立的、可在开发者平台单独配置权限的实体App ID：它的Bundle ID是宿主App Bundle ID下追加.Clips后缀的子标识，和宿主App归属同一个APNs信任域，不存在独立的证书校验流程。

实际推送发送的注意事项 #

• 证书通用不代表device token通用：宿主App和App Clip分别执行推送注册流程拿到的device token是两个完全独立的值。你只需要在服务端对不同场景获取到的token做好来源标记（比如区分是宿主App获取的还是App Clip获取的），直接用现有凭证就可以分别向两个组件发送远程推送，不需要切换证书或鉴权方式。
• 几个开发中常见的踩坑点：
  • 不要手动为App Clip在开发者平台创建带.Clips后缀的独立App ID并配置推送能力，这会直接破坏App Clip和宿主App的关联校验关系，反而导致APNs连通失败。
  • App Clip的推送通道和自身生命周期绑定：受系统机制限制，App Clip最长仅能留存30天，一旦被系统回收或被用户手动移除，对应的App Clip端device token会立刻失效，此时服务端发推送会收到APNs返回的token过期提示，这是正常机制，和证书配置无关。
  • 用户在App Clip内授予的通知权限，会自动同步到用户设备上安装的同开发者宿主App的通知设置里，不需要用户在宿主App端重新完成一次授权流程。

内容的提问来源于stack exchange，提问作者David J