苹果 App Clip 技术详解

苹果在 WWDC2020 上发布了 App Clip，有媒体叫作“苹果小程序”。虽然 Clip 在产品理念上和小程序有类似之处，可是在技术实现层面倒是大相径庭的东西。本文会针对 Clip 的技术层面作全面的介绍。

实现方式：native 代码、native 框架、native app 同样的分发

在实现上，Clip 和原生的 app 使用同样的方式。在 UI 框架上同时支持 UIKit 和 SwiftUI，有些开发者认为只能使用 SwiftUI 开发，这点是错误的。Clip 的定位和 watch app、app extension 相似，和 app 在同一个 project 里，是一个单独的 target。只是 Clip 并无本身的专属 framework（其实有一个，可是主要包含的是一些特点 api），使用的框架和 app 一致，能够认为是一个精简版的原生 App。

Clip 不能单独发布，必须关联一个 app。所以发布的流程和 app 和同样的，在 apple connect 上建立一个版本，和 app 一块儿提交审核。和 app 在技术上的最大区别只是大小限制在 10MB 之内，由于 Clip 的基础就是但愿用户能够最迅速的被用户使用，若是体积大了就失去了产品的根本。

产品定位：用完即走

苹果对 Clip 的使用场景很是明确：在一个特定的情境里，用户能够快速的使用 app 的核心服务。是小程序内味了！ 坦率的说，很难说 Clip 的理念是苹果原创的，在产品的定位上和微信小程序一模一样。尤为是微信小程序在国内已经彻底普及了，微信小程序初始发布的时候也被苹果加了多条限制。其中一条就是小程序不能有虚拟商品支付功能。如今回头看苹果本身的 Clip 能够完美支持 apple pay，很难说苹果没有私心。

触手可及

Clip 使用一段 URL 标识本身，格式听从 universal link。由于苹果对 Clip 的使用场景很是明确，因此在 Clip 的调起方式作了严格限制。Clip 的调用只能是用户主动要发起才能访问，因此不存在用户在某个 app 里不当心点了一个按钮，就跳转下载了 Clip。 Clip 的发起入口有如下几种：

• NFC
• 二维码
• Safari 中关联了 Clip 的网页
• 苹果消息应用
• Siri 附近建议和苹果地图

NFC 和二维码的入口很容易理解，必须用户主动拿出手机靠近 NFC、打开相机扫描。苹果专属的 Clip 码生成工具在年末才会开放。

Safari 中发起和以前的 universal link 相似，在网站配置了关联的 Clip 信息后，会有一个 banner 提示打开应用。

由于 Clip 提交 app store 审核的信息里也会配置好相关的 url，所以若是在 message 里发了 clip 的连接，操做系统也会在应用里生成一个 Clip 的卡片，用户若是须要能够主动点击。

Siri 附近建议和苹果地图（在 connect 中能够配置 clip 的地理位置）。场景和前面的二维码相似，若是我在地图上看到一个商家，商家有提供服务的 Clip，我能够在地图或者 Siri 建议里直接打开 Clip。

再次总结一下 Clip 的入口限制： 只能是用户主动发起才能访问。虽然 Clip 的入口是一段 universal link，在代码里的处理方式也和 universal link 一致，可是为了 Clip 不被滥用，Clip 的调起只能是操做系统调起。App 没有能力主动调起一个 Clip 程序。

无需安装、卸载

由于 Clip 的大小被限制在了 10MB 如下，在当下的网络状态下，能够实现快速的打开。为了给用户使用很是轻松的感受，在 UI 上不会体现“安装”这样的字眼，而是直接“打开”。预期的场景下用户打开 Clip 和打开一个网页相似。所以在用户的视角里就不存在软件的安装、卸载。 Clip 的生命周期由操做系统全权接管。若是 Clip 用户一段时间后没有使用，操做系统就会自动清除掉 Clip，Clip 里存储的数据也会被一并清除。所以虽然 Clip 提供了存储的能力，可是程序不该该依赖存储的数据，只能把存储当作 cache 来使用，操做系统可能自动清除缓存的数据。

横向比较：PWA、Instant Apps、小程序

Instant Apps

18 年正式发布的 Android Instant apps 和 Clip 在技术上是最接近的。Instant apps 中文被翻成“免安装应用”，在体验上也是但愿用户可以最低成本的使用上 app，让用户感觉不到安装这个步骤。Instant apps 也能够经过 url 标识（deep link），若是在 chrome 里搜索到应用的网站，chrome 若是识别到域名下有关联应用，能够直接“打开”。消息中的连接也能够被识别。只是 Instant apps 发布的早，国外用户也没有使用二维码的习惯，因此入口上不支持二维码、NFC。 二者的根本区别仍是在定位上，Instant apps 提出的场景是提供一个 app 的试用版。所以场景是你已经到了 app 的下载页面，这个时候若是一个 app 几百兆你可能就放弃下载了，可是有一个极简的试用版，就会提升你使用 app 的可能。这个场景在游戏 app 里尤为明显，一方面高质量的游戏 app 体积比较大。另外一方面，若是是一个付费下载的应用，若是有一个免费的试用版，也能够增长用户的下载可能。在苹果生态里不少应用会提供一个受限的免费 lite 版本也是同样的需求。 可是 Instant apps 在国内没有产生任何影响。由于政策的缘由，Google Play 不支持在国内市场使用。国内的安卓应用市场也是鱼龙混杂，对于 Instant apps 也估计也没有统一支持。另外国内的安卓生态也和欧美地区区别比较大，早期安卓市场上收费的应用不多，对于用户而言须要试用免费 app 的场景不多。另外大厂也可能会推出专门的急速版应用，安装后利用动态化技术下发代码，应用体积也能够控制在 10 MB 之内。 Clip 则是很是明确的面向线下提供服务的场景，在应用能力上能够接入 sign in with apple，apple pay。这样一个全新的用户，能够很快速的使用线下服务而且进行注册、支付。用户体验会好的多。安卓由于国内生态的缘由，各个安卓厂商没有统一的新用户能够快速注册的接口，也没有统一的支付接口，很难提供相匹敌的体验。若是开发者针对各个厂商单独开发，那成本上就不是“小程序”了。

Progressive Web App(PWA)

Progressive Web App 是基于 web 的技术。在移动互联网兴起以后，你们的流量都转移到了移动设备上。然而在移动上的 web 体验并很差。因而 W3C 和谷歌就基于浏览器的能力，制定了一套协议，让 web app 能够拥有更多的 native 能力。

PWA 不是特指某一项技术，而是应用了多项技术的 Web App。其核心技术包括 App Manifest、Service Worker、Web Push。

PWA 至关于把小程序里的代码直接下载到了本地，有了独立的 app 入口。运行的时候基于浏览器的能力。可是对于用户感觉和原生 app 同样。 我我的对 PWA 技术颇有好感，它的初衷有着初代互联网般的美好。但愿底层有一套协议后，用户体验仍是没有边界的互联网。然而时代已经变了。PWA 在中国基本上是凉了。 PWA 从出生就带了硬伤，虽然谷歌但愿有一套 web 标准能够运行在移动设备上，可是对于苹果的商业策略而言，这并不重要。所以 PWA 的一个协议，从制定出来，再到移动设备（iOS）上支持这个特性，几年就过去了。并且对于移动用户而言，能够拥有一个美好的 web app 并非他们的痛点。 总结起来 PWA 看着美好，但彷佛更可能是对于 web 开发者心中的美好愿景。在落实中遇到了不少现实的问题，技术支持的很差，开发者就更没有动力在这个技术上作软件生态了。

微信小程序

前面提过在产品理念上小程序和 Clip 很类似，甚至说不定 Clip 是受了小程序的启发。在市场上，小程序是 Clip 的真正对手。 小程序基于微信的 app，Clip 基于操做系统，所以在能力上 Clip 有优点。小程序的入口须要先打开微信，而 Clip 能够经过 NFC 靠近直接激活应用。对于开发者而言，Clip 能够直接得到不少原生的能力（好比 push），若是用户喜欢能够关联下载本身的原生应用。在小程序中，微信出于商业缘由开发者不能直接跳转到自有 app，小程序的能力也依赖于微信提供的接口。 对于从 Clip 关联主 app 苹果还挺重视的，提供了几个入口展现关联 app。 首先在 clip 的展现页就会显示：

每次使用 Clip 时也会有一个短暂的浮层展现：

开发者也能够本身经过 SKOverlay 来展现：

不过若是开发者没有本身的独立 app，那么也就只能选择小程序了。小程序发展到如今场景也比最先提出的线下服务更加多了，反而相似 Instant apps，更像一个轻量级的 app。 考虑到国内不少小程序的厂商都没有本身的独立 app，所以 clip 对于这部分群体也并无什么吸引力。不过对于线下服务类，尤为有支付场景的，Clip 在用户体验上会比小程序好一些。 总结，Clip 的业务场景和小程序有一小部分是重叠的，小程序覆盖的场景仍是更多一些。二者在大部分时候并非互斥式的竞争关系，即使在一些场景下 Clip 有技术优点，商家也不会放弃小程序，由于还有安卓用户嘛。仍是看商家在某些场景里，是否愿意为用户多提供一种更好的交互方式。

对比原生 app 的技术限制

虽然 Clip 能够直接使用 iOS framework，可是由于 Clip 的使用场景是新用户的初次、简短、当下（in-the-moment experience）的使用，相比原生 app 苹果仍是进行了一些限制。 App 不能访问用户的隐私信息：

• 运动和健身数据
• Apple Music 和多媒体文件
• 通信录、信息、照片、文件等数据

不过为了可以提供给用户更加轻便的体验，经过专门为 Clip 设计了免申请的通知、定位权限。不过也有限制：免申请的通知只在 8 个小时内有效。位置只能获取一次。若是 app 须要重度使用这两类权限就仍是和原来同样，能够弹窗申请。 某些高级应用能力也会受限，须要在完整的应用中才能使用：

• 不能请求追踪受权
• 不能进行后台请求任务
• 没在激活状态蓝牙链接会断开

总的而言虽然有一些限制，可是这些限制的出发点是但愿开发者关注 Clip 的正确使用场景。对于 Clip 所提倡的使用场景里，苹果提供的能力是彻底够用的。

一些技术细节

能够创建一个共享 targets 的 Asset catalog 来共用图片资源。

在 Clip 中申请的受权，在下载完整应用后会被同步到应用中。 经过 App Group Container 来共享 clip 和 app 的数据。

Clip 的 url 能够配置参数：

在 App Store connect 中还能够针对指定的参数配置不同的标题和图片。好比一家连锁咖啡店，可能不一样的店你但愿弹出的标题图片是不同的，能够进行单独的配置。

总结

苹果给定义的 Clip 的关键词是：lightweight、native、fast、focused、in-the-moment experience。 Clip 在特定的线下场景里有着至关好的用户体验。对于已经拥有独立 app 的公司来讲，开发一个 clip 应用的成本并不高。我我的仍是期待这样一个好的技术能够被更多开发者接纳，能够提供给用户更好的体验。对于小程序，clip 的场景窄的多，二者并非直接竞争关系。我更愿意看作是特定场景下，对于小程序原生能力不足的一种补充。